Re: xlog.c: WALInsertLock vs. WALWriteLock

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.

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