Re: Buffer access rules, and a probable bug

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
> >> 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(at)zembu(dot)com