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

Re: Buffer access rules, and a probable bug

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Buffer access rules, and a probable bug
Date: 2001-07-03 22:59:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jul 03, 2001 at 05:11:46PM -0400, Tom Lane wrote:
> ncm(at)zembu(dot)com (Nathan Myers) writes:
> > On Mon, Jul 02, 2001 at 09:40:25PM -0400, Tom Lane wrote:
> >> 4. It is considered OK to update tuple commit status bits (ie, OR the
> >> HEAP_XMAX_INVALID into t_infomask) while holding only a shared lock and
> >> pin on a buffer.  This is OK because another backend looking at the tuple
> >> at about the same time would OR the same bits into the field, so there
> >> is little or no risk of conflicting update; what's more, if there did
> >> manage to be a conflict it would merely mean that one bit-update would
> >> be lost and need to be done again later.
> > Without looking at the code, this seems mad.  Are you sure?
> Yes.  Those status bits aren't ground truth, only hints.  They cache the
> results of looking up transaction status in pg_log; if they get dropped,
> the only consequence is the next visitor to the tuple has to do the
> lookup over again.
> Changing any other bits in t_infomask requires exclusive lock, however.

Hmm, look:

    A                  B

1   load t_infomask


3                      lock

4                      load t_infomask

5                      or MOVED_IN

6                      store t_infomask

7                      unlock

8    store t_infomask

Here, backend B is a good citizen and locks while it makes its change.  
Backend A only means to touch the "hint" bits, but it ends up clobbering
the MOVED_IN bit too.

Also, as hints, would it be Bad(tm) if an attempt to clear one failed?
That seems possible as well.

Nathan Myers

In response to


pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2001-07-03 23:30:16
Subject: Re: stuck spin lock with many concurrent users
Previous:From: Bruce MomjianDate: 2001-07-03 22:44:29
Subject: Re: [OT] Any major users of postgresql?

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