On 2016-06-21 13:03:24 -0400, Robert Haas wrote: > On Tue, Jun 21, 2016 at 12:54 PM, Andres Freund <and...@anarazel.de> wrote: > >> I don't quite understand the intended semantics of this proposed flag. > > > > Whenever the flag is set, we have to acquire the heavyweight tuple lock > > before continuing. That guarantees nobody else can modify the tuple, > > while the lock is released, without requiring to modify more than one > > hint bit. That should fix the torn page issue, no? > > Yeah, I guess that would work. > > >> If we don't already have the tuple lock at that point, we can't go > >> acquire it before releasing the content lock, can we? > > > > Why not? Afaics the way that tuple locks are used, the nesting should > > be fine. > > Well, the existing places where we acquire the tuple lock within > heap_update() are all careful to release the page lock first, so I'm > skeptical that doing it the other order is safe. Certainly, if we've > got some code that grabs the page lock and then the tuple lock and > other code that grabs the tuple lock and then the page lock, that's a > deadlock waiting to happen.
Just noticed this piece of code while looking into this: UnlockReleaseBuffer(buffer); if (have_tuple_lock) UnlockTupleTuplock(relation, &(tp.t_self), LockTupleExclusive); if (vmbuffer != InvalidBuffer) ReleaseBuffer(vmbuffer); return result; seems weird to release the vmbuffer after the tuplelock... > I'm also a bit dubious that LockAcquire is safe to call in general > with interrupts held. Looks like we could just acquire the tuple-lock *before* doing the toast_insert_or_update/RelationGetBufferForTuple, but after releasing the buffer lock. That'd allow us to do avoid doing the nested locking, should make the recovery just a goto l2;, ... Andres -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers