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

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

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 04:45:13
Message-ID: 3B43F0D9.165403FA@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-07-05 07:28:24
Subject: Re: stuck spin lock with many concurrent users
Previous:From: Bruce MomjianDate: 2001-07-05 03:16:18
Subject: Re: Re: Buffer access rules, and a probable bug

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