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

Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.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