kvserver: unexpected non-locking read handling during FK check #111429
Assignees
Labels
A-read-committed
Related to the introduction of Read Committed
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
Comments
michae2
added
C-bug
|
Ah, Nathan figured it out: #110945 (comment) |
arulajmani
added a commit
to arulajmani/cockroach
that referenced
this issue
Sep 28, 2023
Over in cockroachdb#111429, we saw a non-locking read request which specified a key locking durability of lock.Replicated. This is not allowed -- however, the resulting panic message can be improved. Epic: none Release note: None
|
This will be fixed by #109638 |
arulajmani
added a commit
to arulajmani/cockroach
that referenced
this issue
Sep 29, 2023
Over in cockroachdb#111429, we saw a non-locking read request which specified a key locking durability of lock.Replicated. This is not allowed -- however, it doesn't warrant a panic on the server. We fix this and improve the error message. Epic: none Release note: None
craig bot
pushed a commit
that referenced
this issue
Sep 29, 2023
111190: sql: add SHOW EXPERIMENTAL_FINGERPRINTS FROM VIRTUAL CLUSTER r=knz,msbutler a=stevendanna This adds a user-facing interface for tenant fingerprinting that does not require crdb_internal functions. We've moved the underlying implementation to a function that lives on the planner so that it can be shared from both call sites. Additionally, - we now issue the ExportRequests in parallel, and - we allow users with MANAGETENANT to issue the fingerprint command. Epic: none Release note: None 111432: kv: do not panic when non-locking read requests ask for replicated locks r=nvanbenschoten a=arulajmani Over in #111429, we saw a non-locking read request which specified a key locking durability of lock.Replicated. This is not allowed -- however, it doesn't warrant a panic on the server. We fix this and improve the error message. Epic: none Release note: None Co-authored-by: Steven Danna <[email protected]> Co-authored-by: Arul Ajmani <[email protected]>
THardy98
pushed a commit
to THardy98/cockroach
that referenced
this issue
Oct 6, 2023
Over in cockroachdb#111429, we saw a non-locking read request which specified a key locking durability of lock.Replicated. This is not allowed -- however, it doesn't warrant a panic on the server. We fix this and improve the error message. Epic: none Release note: None
|
Fixed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With #110945 applied, we have replicated locks wired up to SQL for the first time. It looks like we're running into a panic when performing a FK check, which tries to take a shared guaranteed-durable lock on a single row. The FK check is performing a
Scan [/Table/104/1/1/0,/Table/104/1/1/1)with shared guaranteed-durable locking, which results in this panic:To reproduce it, use the PR branch:
The repro steps are to execute an INSERT that has a FK check:
(This can also be reproduced with
./dev testlogic base --config=local --files=fk_read_committedwhich is a logic test that does the same thing.)Here's the explain of that insert:
This happens regardless of whether we're using
enable_insert_fast_pathor not.Jira issue: CRDB-31894
The text was updated successfully, but these errors were encountered: