Re: Buffer access rules, and a probable bug

On Tue, Jul 03, 2001 at 05:11:46PM -0400, Tom Lane wrote:
> ncm@zembu.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
> >> values HEAP_XMIN_COMMITTED, HEAP_XMIN_INVALID, HEAP_XMAX_COMMITTED, or
> >> 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

2   or XMIN_INVALID

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
ncm@zembu.com