Re: Re: Buffer access rules, and a probable bug

Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > What I mean is to implement a new function
> > HeapTupleSatisfiesAny() as
>
> > bool
> > HeapTupleSatisfiesAny(HeapTupleHeader tuple)
> > {
> > HeapTupleSatisfiesNow(tuple);
> > return true;
> > }
>
> Oh, I see: so that HeapTupleSatisfies would update the hint bits even
> when called with snapshot = SnapShotAny. Hmm. This might be a good
> idea on its own merits, but I don't think it simplifies nbtree.c at
> all --- you'd still have to go through the full LockBuffer and hint
> update procedure there. (If the other transaction committed meanwhile,
> the call from nbtree.c could try to update hint bits that hadn't been
> updated during heap_fetch.)
>

Dead(HEAP_XMAX_COMMITTED || HEAP_XMIN_INVALID) tuples never
revive. Live (not dead) tuples never die in Share Lock mode.
So I don't have to call HeapTupleSatisfies() again though I
seem to have to lock the buffer so as to see t_infomask and
t_xmax.

> BTW, I don't really think that this code belongs in nbtree.c at all.
> If it lives there, then we need to duplicate the logic in each index
> access method. At some point we ought to fix the index build process
> so that the loop that scans the source relation is outside the access-
> method-specific code.
>

Agreed.

regards,
Hiroshi Inoue