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. I'm also a bit dubious that LockAcquire is safe to call in general with interrupts held. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
