On Sat, 2012-11-17 at 16:53 -0500, Tom Lane wrote:
> Jeff Davis <pg...@j-davis.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
