Re: Buffer access rules, and a probable bug

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.

regards, tom lane