On Tue, Oct 26, 2010 at 11:23 AM, Robert Haas
<robertmhaas@gmail.com> wrote:
On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
<
heikki.linnakangas@enterprisedb.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.
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.