Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group