On 21.09.2013 23:46, Andres Freund wrote:
Heikki Linnakangas<hlinnakan...@vmware.com> schrieb:
Kevin Grittner<kgri...@ymail.com> wrote:
Andres Freund<and...@2ndquadrant.com> wrote:
On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
When a tuple is predicate-locked, the key of the lock is
ctid+xmin.
However, when a tuple is frozen, its xmin is changed to FrozenXid.
That
effectively
invalidates any predicate lock on the tuple, as checking for a
lock
on
the
same tuple later won't find it as the xmin is different.
Attached is an isolationtester spec to demonstrate this.
Do you have any idea to fix that besides keeping the xmin horizon
below the
lowest of the xids that are predicate locked? Which seems nasty to
compute and is probably not trivial to fit into the procarray.c
machinery?
A better solution probably is to promote tuple-level locks if they
exist
to a relation level one upon freezing I guess?
That would work. A couple other ideas would be to use the oldest
serializable xmin which is being calculated in predicate.c to
either prevent freezing of newer transaction or to summarize
predicate locks (using the existing SLRU-based summarization
functions) which use xmin values for xids which are being frozen.
The transactions must already be committed, and so are eligible for
summarization.
What's the point of using xmin as part of the lock key in the first
place, wouldn't ctid alone suffice? If the tuple was visible to the
reading transaction, it cannot be vacuumed away until the transaction
commits. No other tuple can appear with the same ctid.
SSI locks can live longer than one TX/snapshot.
Hmm, true.
Another idea: we could vacuum away predicate locks, when the
corresponding tuples are vacuumed from the heap. Before the 2nd phase of
vacuum, before removing the dead tuples, we could scan the predicate
lock hash and remove any locks belonging to the tuples we're about to
remove. And not include xmin in the lock key.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
