Re: Re: Buffer access rules, and a probable bug - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: Buffer access rules, and a probable bug
Date
Msg-id 1597.994295099@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: Buffer access rules, and a probable bug  (Hiroshi Inoue <Inoue@tpf.co.jp>)
List pgsql-hackers
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.)

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Re: Buffer access rules, and a probable bug
Next
From: Bruce Momjian
Date:
Subject: Re: Re: Buffer access rules, and a probable bug