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 offset 265 nmembers 2: > 248477 (nokeyupd) 248500 (keysh) > rmgr: Heap len (rec/tot): 70/ 70, tx: 248477, lsn: > 0/66DB82E0, prev 0/66DB82A8, desc: HOT_UPDATE off 20 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-23 20:33:03.712298 UTC > … > rmgr: Transaction len (rec/tot): 34/ 34, tx: 248645, lsn: > 0/66DBB060, prev 0/66DBB020, desc: ABORT 2022-11-23 20: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"
