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

Re: xlog.c: WALInsertLock vs. WALWriteLock

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: fazool mein <fazoolmein(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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 19:00:05
Message-ID: AANLkTimjmRQXoZFe8wVDuc6v=DtSWBU5GTJT5aCumKWN@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Oct 26, 2010 at 2:57 PM, fazool mein <fazoolmein(at)gmail(dot)com> wrote:
>
> On Tue, Oct 26, 2010 at 11:23 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> >
>> >> 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.
>>
>
> I agree that the standby might get ahead, but this doesn't necessarily lead
> to database corruption. Here, the interesting case is what happens when the
> primary fails, which can lead to *either* of the following two cases:
> 1) The standby, due to some triggering mechanism, becomes the new primary.
> In this case, even if the standby was ahead, its fine.

True.

> 2) The primary comes back as primary. In this case, the standby will connect
> again to the primary. At this point, *if* somehow we are able to detect that
> the standby is ahead, then we should abort the standby and create a standby
> from scratch.

Unless you set restart_after_crash=off, the master could
crash-and-restart before you can do anything about it.  But that
doesn't exist in the 9.0 branch.

> I agree with Heikki that going through all this trouble only makes sense if
> there is a huge performance boost.

There's probably quite a large performance boost in the sync rep case
from allowing the master and standby to fsync() in parallel, but first
we need to get something that works at all.

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

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-10-26 19:02:27
Subject: Re: xlog.c: WALInsertLock vs. WALWriteLock
Previous:From: fazool meinDate: 2010-10-26 18:57:22
Subject: Re: xlog.c: WALInsertLock vs. WALWriteLock

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