I notice that heap_update releases the buffer lock, after checking the
HeapTupleSatifiesUpdate result, and before marking the tuple as updated,
to pin the visibility map page -- heapam.c lines 2638ff in master branch.
Is this not a bug? I imagine that while this code releases the lock,
someone else could acquire it and grab a FOR SHARE lock on the tuple; if
the update later ends up modifying the tuple completely, this could
cause an FK to be broken, for example.
The other piece of that routine that releases the buffer lock, to toast
the tuple, is careful enough to set the Xmax to itself before releasing
the lock, which seems to me the right thing to do, because then the
prospective locker would have to wait until this transaction finishes
before being able to grab the lock. Is this not necessary in the other
path? If so, why?
The reason I care is because I need to do something to this code for the
FOR KEY SHARE stuff I'm working on (not yet sure what).
(I CC both Robert and Heikki because I don't remember whose work it was
on the VM stuff).
--
Álvaro Herrera <alvherre@alvh.no-ip.org>
