Re: SSI freezing bug

On 22.09.2013 00:12, Hannu Krosing wrote:
> On 09/21/2013 10:46 PM, Andres Freund wrote:
>>
>> 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.
> But the only way that ctid can change without xmin changing is when
> you update the tuple in the same TX that created it.

I don't think that's relevant. We're not talking about the "ctid" field 
of a tuple, ie. HeapTupleHeader.t_ctid. We're talking about its physical 
location, ie. HeapTuple->t_self.

- Heikki