kvserver/concurrency: allow lock acquisition out of seq num order#46019
kvserver/concurrency: allow lock acquisition out of seq num order#46019craig[bot] merged 1 commit intocockroachdb:masterfrom
Conversation
This commit updates the lock-table to allow lock acquisition at a sequence number below but not contained within an existing lock's sequence number history. This is not possible to exercise when locks are only added to the lock-table using AcquireLock, but is possible when a later sequence number is added to the lock=table through AddDiscoveredLock before the lock-table is notified of the corresponding sequence of lock acquisitions. This is possible because we do not immediately add replicated locks to the lock-table. This means that a txn might acquire a lock at sequence 2 and 3 with neither being added to the lock-table. A second txn might then "discover" the lock and add it at seq 3 to the lock-table. If the first txn was to then replay its batch with sequence 2 and 3, it would have previously hit the assertion. I saw this while stressing kvnemesis. Release justification: low risk bug fix
|
This change is |
ajwerner
left a comment
There was a problem hiding this comment.
Reviewed 2 of 2 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @sumeerbhola)
|
TFTR! bors r+ |
Build failed |
sumeerbhola
left a comment
There was a problem hiding this comment.
This means that a txn might acquire a
lock at sequence 2 and 3 with neither being added to the lock-table.
Is this also triggered if 2 was replicated and 3 was unreplicated, so due to the lack of contention only 3 was known to the lockTable and then the replay added 2?
Reviewed 2 of 2 files at r1.
Reviewable status:
I don't think so, but only because of how we store replicated and unreplicated locks with their own sequence histories each. Lint failed with:
bors r+ |
Build succeeded |
This commit updates the lock-table to allow lock acquisition at
a sequence number below but not contained within an existing
lock's sequence number history. This is not possible to exercise
when locks are only added to the lock-table using AcquireLock,
but is possible when a later sequence number is added to the
lock=table through AddDiscoveredLock before the lock-table is
notified of the corresponding sequence of lock acquisitions.
This is possible because we do not immediately add replicated
locks to the lock-table. This means that a txn might acquire a
lock at sequence 2 and 3 with neither being added to the lock-table.
A second txn might then "discover" the lock and add it at seq 3
to the lock-table. If the first txn was to then replay its batch
with sequence 2 and 3, it would have previously hit the assertion.
I saw this while stressing kvnemesis.
Release justification: low risk bug fix that prevents a fatal server crash