Re: HeapTupleSatisfiesToast not setting XMIN_COMMITTED?

On Wed, Sep 21, 2011 at 2:14 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
>
> Excerpts from Merlin Moncure's message of mié sep 21 16:02:34 -0300 2011:
>> On Wed, Sep 21, 2011 at 1:03 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> >
>> > Hi,
>> >
>> > I notice that HeapTupleSatisfiesToast is not setting the
>> > HEAP_XMIN_COMMITTED bit, though it is reading it.  Is there a reason for
>> > this?  It seems to me that it'd make sense to have it set ... unless
>> > it's set by some other routine, somehow?
>>
>> I think it's implied from the untoasted row.  Notice that it's not
>> checking visibility either except in binary upgrade cases.
>
> Yeah, so toast visibility is highly dependant to the referencing row.
> Which makes sense.  But then, if the XMIN_COMMITTED bit is not set,
> you're forced to check the other bits every time.  I guess the tradeoff
> is that if you set it, the page is dirtied and you're forced to write it
> down, which is even worse.

yeah -- there's no way it's worth the i/o in that case, since there's
no visibility check to protect yourself from.

> More interesting, however, is the fact that the XMAX_COMMITTED bit is
> never set either.  I guess the rows are deleted by a different mechanism
> (tuptoaster probably) -- it isn't obvious how this works just by looking
> at tqual.c.  It seems to do nothing at all.

yup -- probably the only reason it exists at all is vacuum issues
which all visibility routines have to handle. otherwise, it's a fancy
'return true'.

merlin