Re: Do we need so many hint bits?

On Sat, 2012-11-17 at 16:53 -0500, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > What's the problem with that? If you already have the VM buffer pinned
> > (which should be possible if we keep the VM buffer in a longer-lived
> > structure), then doing the test is almost as cheap as checking
> > PD_ALL_VISIBLE, because you don't need any locks.
>
> Really? What about race conditions? Specifically, I think what you
> suggest is likely to be unreliable on machines with weak memory
> ordering. Consider possibility that someone else just changed the VM
> bit. Getting a lock ensures synchronization. (Yeah, it's possible that
> we could use some primitive cheaper than a lock ... but it's not going
> to be free.)

There's already a similar precedent in IndexOnlyNext, which calls
visibilitymap_test with no lock.

I am not authoritative on these kinds of lockless accesses, but it looks
like we can satisfy those memory barrier requirements in the places we
need to.

Here is my analysis:

Process A (process that clears a VM bit for a data page):
1. Acquires exclusive lock on data buffer
2. Acquires exclusive lock on VM buffer
3. clears VM bit
4. Releases VM buffer lock
5. Releases data buffer lock

Process B (process that tests the VM bit for the same data page):
1. Acquires shared lock (if it's a scan doing a visibility test) or an
exclusive lock (if it's an I/U/D that wants to know whether to clear the
bit or not) on the data buffer.
2. Tests bit using an already-pinned VM buffer.
3. Releases data buffer lock.

Process A and B must be serialized, because A takes an exclusive lock on
the data buffer and B takes at least a shared lock on the data buffer.
The only dangerous case is when A happens right before B. So, the
question is: are there enough memory barriers between A-3 and B-2? And I
think the answer is yes. A-4 should act as a write barrier after
clearing the bit, and B-1 should act as a read barrier before reading
the bit.

Let me know if there is a flaw with this analysis.

If not, then I still agree with you that it's not as cheap as testing
PD_ALL_VISIBLE, but I am skeptical that memory-ordering constraints
we're imposing on the CPU are expensive enough to matter in these cases.
If you have a test case in mind that might exercise this, then I will
try to run it (although my workstation is only 4 cores, and the most I
can probably get access to is 16 cores).

Regards,
Jeff Davis