Re: xlog.c: WALInsertLock vs. WALWriteLock

On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 26.10.2010 21:03, fazool mein wrote:
>>>
>>> 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.
>>>
>> That is exactly what I do not want to do, i.e. read from disk, as long as
>> the piece of WAL is available in the buffers.
>
> Why not? If the reason is performance, I'd like to see some performance
> numbers to show that it's worth the trouble. You could perhaps do a quick
> and dirty hack that doesn't do the locking 100% correctly first, and do some
> benchmarking on that to get a ballpark number of how much potential there
> is. Or run oprofile on the current walsender implementation to see how much
> time is currently spent reading WAL from the kernel buffers.
>
>> Can you please describe why
>> walsender reading directly from the buffers was given up? To avoid a lot
>> of
>> locking?
>
> To avoid locking yes, and complexity in general.

And the fact that it might allow the standby to get ahead of the
master, leading to silent database corruption.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company