Re: xlog.c: WALInsertLock vs. WALWriteLock

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