Skip site navigation (1) Skip section navigation (2)

Re: xlog.c: WALInsertLock vs. WALWriteLock

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: fazool mein <fazoolmein(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xlog.c: WALInsertLock vs. WALWriteLock
Date: 2010-10-26 18:23:32
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: David FetterDate: 2010-10-26 18:31:45
Subject: EOCF
Previous:From: Peter EisentrautDate: 2010-10-26 18:20:09
Subject: security label error message

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group