On Wed, Sep 21, 2011 at 2:14 PM, Alvaro Herrera
<alvherre@commandprompt.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@alvh.no-ip.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