Hi,
On 2021-10-29 15:06:52 -0700, Peter Geoghegan wrote:
> On Fri, Oct 29, 2021 at 1:49 PM Andres Freund <andres@anarazel.de> wrote:
> > > rmgr: Heap len (rec/tot): 59/ 8115, tx: 2085600, lsn:
> > > 2/A0165A70, prev 2/A0165A38, desc: LOCK off 22: xid 2085600: flags 0x00
> > > LOCK_ONLY EXCL_LOCK KEYS_UPDATED , blkref #0: rel 1663/19243/19560 blk 540
> > > FPW
> > > rmgr: Heap len (rec/tot): 54/ 54, tx: 2085600, lsn:
> > > 2/A018E858, prev 2/A018D7D8, desc: LOCK off 22: xid 2085600: flags 0x00
> > > LOCK_ONLY EXCL_LOCK KEYS_UPDATED , blkref #0: rel 1663/19243/19560 blk 540
> > > rmgr: Heap len (rec/tot): 73/ 8237, tx: 2085600, lsn:
> > > 2/A018E890, prev 2/A018E858, desc: UPDATE off 22 xmax 2085600 flags 0x03
> > > KEYS_UPDATED ; new off 21 xmax 2085600, blkref #0: rel 1663/19243/19560 blk
> > > 328 FPW, blkref #1: rel 1663/19243/19560 blk 540
> >
> > This is also odd. Why are we locking the same row twice, in the same
> > transaction?
>
> My guess is that mediawiki is supposed to be usable with at least
> MySQL, Postgres, and SQLite, and so uses SELECT FOR UPDATE in ways
> that seem excessive to us.
I was wondering from a different angle:
The two locks are from the same transaction. As far as I remember that code we
actually shouldn't end up emitting a separate lock if the lock level is the
same.
Just briefly looking over the code, the second heap_lock_tuple() should get a
TM_BeingModified from HTSU, which should then end up in the
TransactionIdIsCurrentTransactionId(xwait)) branch, resulting in a goto
out_unlocked.
Greetings,
Andres Freund