Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Jeff Janes's message of mar oct 26 12:22:38 -0300 2010:
>> I don't think that holding WALWriteLock accomplishes much. It
>> prevents part of the buffer from being written out to OS/disk, and
>> thus becoming eligible for being overwritten in the buffer, but the
>> WALInsertLock prevents it from actually being overwritten. And what
>> if the part of the buffer you want to read was already eligible for
>> overwriting but not yet actually overwritten? WALWriteLock won't
>> allow you to safely access it, but WALInsertLock will (assuming you
>> have a safe way to identify the record in the first place). For
>> either case, holding it in shared mode would be sufficient.
> And horrible for performance, I imagine. Those locks are highly trafficked.
I think you might actually need *both* locks to ensure the WAL buffers
aren't changing underneath you. If you don't have the walwriter locked
out, it is free to change the state of a buffer from "dirty" to
"written" and then to "prepared to receive next page of WAL". If the
latter doesn't involve changing the content of the buffer today, it
still could tomorrow.
And on top of all that, there remains the problem that the piece of WAL
you want might already be gone from the buffers.
Might I suggest adopting the same technique walsender does, ie just read
the data back from disk? There's a reason why we gave up trying to have
walsender read directly from the buffers.
regards, tom lane
