On 2022-Nov-24, Alvaro Herrera wrote: > On 2022-Nov-24, Dimos Stamatakis wrote: > > > 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.
Hmm, if a transaction is aborted but its Xid is after latestCompletedXid, it would be reported as still running. AFAICS that is only modified with ProcArrayLock held in exclusive mode, and only read with it held in share mode, so this should be safe. I can see nothing else ATM. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "I must say, I am absolutely impressed with what pgsql's implementation of VALUES allows me to do. It's kind of ridiculous how much "work" goes away in my code. Too bad I can't do this at work (Oracle 8/9)." (Tom Allison) http://archives.postgresql.org/pgsql-general/2007-06/msg00016.php
