On 2013-10-04 13:51:00 +0300, Heikki Linnakangas wrote: > On 04.10.2013 13:23, Andres Freund wrote: > >On 2013-10-03 21:14:17 -0700, Dan Ports wrote: > >>On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote: > >>>Heikki Linnakangas<hlinnakan...@vmware.com> wrote: > >>>>IMHO it would be better to remove xmin from the lock key, and vacuum > >>>>away the old predicate locks when the corresponding tuple is vacuumed. > >>>>The xmin field is only required to handle the case that a tuple is > >>>>vacuumed, and a new unrelated tuple is inserted to the same slot. > >>>>Removing the lock when the tuple is removed fixes that. > >> > >>This seems definitely safe: we need the predicate locks to determine if > >>someone is modifying a tuple we read, and certainly if it's eligible > >>for vacuum nobody's going to be modifying that tuple anymore. > > > >But we're talking about freezing a tuple, not removing a dead tuple. I > >don't see anything preventing modification of a frozen tuple. Right? > > Right, but if we no longer include xmin in the lock key, freezing a tuple > makes no difference. Currently, the problem is that when a tuple is frozen, > the locks on the tuple on the tuple are "lost", as the xmin+ctid of the lock > no longer matches xmin+ctid of the tuple. > > Removing xmin from the lock altogether solves that problem, but it > introduces the possibility that when an old tuple is vacuumed away and a new > tuple is inserted on the same slot, a lock on the old tuple is confused to > be a lock on the new tuple. And that problem can be fixed by vacuuming > locks, when the corresponding tuple is vacuumed.
But locks on those still can have meaning, right? From my very limited understanding of predicate.c/SSI I don't see why we cannot have meaningful conflicts on tuples that are already vacuumable. You'd need some curiously interleaved transactions, sure, but it seems possible? ISTM we'd need to peg the xmin horizon for vacuum to the oldest xmin predicate.c keeps track of. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
