mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Allow special SKIP LOCKED condition in Assert()

Browse Source 
Under concurrency, it is possible for two sessions to be merrily locking
and releasing a tuple and marking it again as HEAP_XMAX_INVALID all the
while a third session attempts to lock it, miserably fails at it, and
then contemplates life, the universe and everything only to eventually
fail an assertion that said bit is not set.  Before SKIP LOCKED that was
indeed a reasonable expectation, but alas! commit df630b0dd5ea falsified
it.

This bug is as old as time itself, and even older, if you think time
begins with the oldest supported branch.  Therefore, backpatch to all
supported branches.

Author: Simon Riggs <simon.riggs@enterprisedb.com>
Discussion: https://postgr.es/m/CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0ebg@mail.gmail.com
This commit is contained in:
Alvaro Herrera 2022-01-04 13:01:05 -03:00
parent 20d08b2c61
commit 29f9fb8fe8
No known key found for this signature in database
GPG Key ID: 1C20ACB9D5C564AE
1 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/access/heap/heapam.c
View File

@ -4497,7 +4497,15 @@ failed:
{
Assert(result == TM_SelfModified || result == TM_Updated ||
result == TM_Deleted || result == TM_WouldBlock);
Assert(!(tuple->t_data->t_infomask & HEAP_XMAX_INVALID));
/*
* When locking a tuple under LockWaitSkip semantics and we fail with
* TM_WouldBlock above, it's possible for concurrent transactions to
* release the lock and set HEAP_XMAX_INVALID in the meantime. So
* this assert is slightly different from the equivalent one in
* heap_delete and heap_update.
*/
Assert(TM_WouldBlock || !(tuple->t_data->t_infomask & HEAP_XMAX_INVALID));
Assert(result != TM_Updated ||
!ItemPointerEquals(&tuple->t_self, &tuple->t_data->t_ctid));
tmfd->ctid = tuple->t_data->t_ctid;