Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency

On 2022-Nov-24, Dimos Stamatakis wrote:

> Thanks for your feedback!
> I applied the patch to print more information about the error. Here’s what I got:
> 
> 2022-11-23 20:33:03 UTC [638 test_database]: [5458] ERROR:  new multixact has more than one updating member: 0
2[248477(nokeyupd), 248645 (nokeyupd)]
 
> 2022-11-23 20:33:03 UTC [638 test_database]: [5459] STATEMENT:  UPDATE warehouse1
>                           SET w_ytd = w_ytd + 498
>                         WHERE w_id = 5
> 
> I then inspected the WAL and I found the log records for these 2 transactions:
> 
> …
> rmgr: MultiXact   len (rec/tot):     54/    54, tx:     248477, lsn: 0/66DB82A8, prev 0/66DB8260, desc: CREATE_ID 133
offset265 nmembers 2: 248477 (nokeyupd) 248500 (keysh)
 
> rmgr: Heap        len (rec/tot):     70/    70, tx:     248477, lsn: 0/66DB82E0, prev 0/66DB82A8, desc: HOT_UPDATE
off20 xmax 133 flags 0x20 IS_MULTI EXCL_LOCK ; new off 59 xmax 132, blkref #0: rel 1663/16384/16385 blk 422
 
> rmgr: Transaction len (rec/tot):     34/    34, tx:     248477, lsn: 0/66DBA710, prev 0/66DBA6D0, desc: ABORT
2022-11-2320:33:03.712298 UTC
 
> …
> rmgr: Transaction len (rec/tot):     34/    34, tx:     248645, lsn: 0/66DBB060, prev 0/66DBB020, desc: ABORT
2022-11-2320:33:03.712388 UTC
 

Ah, it seems clear enough: the transaction that aborted after having
updated the tuple, is still considered live when doing the second
update.  That sounds wrong.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Puedes vivir sólo una vez, pero si lo haces bien, una vez es suficiente"