Re: Inadequate thought about buffer locking during hot standby replay

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Nov 11, 2012 at 6:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I already pointed out the inconsistency in heap_xlog_freeze about
>> whether a cleanup lock is needed. As is, this patch uses a cleanup
>> lock, but I suspect that a regular lock is sufficient --- comments?

> Well, according to storage/buffer/README:

> 1. To scan a page for tuples, one must hold a pin and either shared or
> exclusive content lock. To examine the commit status (XIDs and status bits)
> of a tuple in a shared buffer, one must likewise hold a pin and either shared
> or exclusive lock.

> That does indeed make it sound like an x-lock is enough.

Yeah. AFAICS, the only possible downside is that somebody might be
using the tuple (while holding just a buffer pin), and that its xmin
might change while that's happening. So for instance a nestloop join
might read out different xmin values for the same row while the join
proceeds. But that could happen anyway if a different plan had been
chosen (viz, this table on the inside not the outside of the nestloop).
The xmin update ought to be physically atomic, so you shouldn't be able
to get a garbage result, just the old value or the new.

The cleanup lock is needed for cases where we'd like to remove or move a
tuple, but that's not required here.

regards, tom lane