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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Buffer access rules, and a probable bug
Date: 2001-07-05 01:04:59
Message-ID: 1597.994295099@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-07-05 03:16:18 Re: Re: Buffer access rules, and a probable bug
Previous Message Hiroshi Inoue 2001-07-04 23:43:24 Re: Re: Buffer access rules, and a probable bug