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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-07-05 07:28:24 | Re: stuck spin lock with many concurrent users |
Previous Message | Bruce Momjian | 2001-07-05 03:16:18 | Re: Re: Buffer access rules, and a probable bug |