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: (view raw, whole thread or download thread mbox)
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.


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