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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-10-26 19:02:27 | Re: xlog.c: WALInsertLock vs. WALWriteLock |
Previous Message | fazool mein | 2010-10-26 18:57:22 | Re: xlog.c: WALInsertLock vs. WALWriteLock |