Heikki Linnakangas <hlinnakangas@vmware.com> schrieb:
>Kevin Grittner <kgrittn@ymail.com> wrote:
>>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.
>
>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.
Andres
--
Please excuse brevity and formatting - I am writing this on my mobile phone.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services