Andres Freund <andres@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.
I'm not sure which is best. Will review, probably this weekend.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
