On 2016-06-21 10:50:36 -0400, Robert Haas wrote: > On Mon, Jun 20, 2016 at 11:51 PM, Andres Freund <and...@anarazel.de> wrote: > >> > So far the best idea I have - and it's really not a good one - is to > >> > invent a new hint-bit that tells concurrent updates to acquire a > >> > heavyweight tuple lock, while releasing the page-level lock. If that > >> > hint bit does not require any other modifications - and we don't need an > >> > xid in xmax for this use case - that'll avoid doing all the other > >> > `already_marked` stuff early, which should address the correctness > >> > issue. > >> > > >> > >> Don't we need to clear such a flag in case of error? Also don't we need to > >> reset it later, like when modifying the old page later before WAL. > > > > If the flag just says "acquire a heavyweight lock", then there's no need > > for that. That's cheap enough to just do if it's errorneously set. At > > least I can't see any reason. > > 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? > 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. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
