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: AANLkTikZBqKdYsga4fLiiTRuYiBF8foqC+-3E+NuH=fA@mail.gmail.com (view raw or flat)
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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

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-2014 The PostgreSQL Global Development Group