Re: Proposal for 9.1: WAL streaming from WAL buffers

On Wed, Jun 30, 2010 at 5:36 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> Before we get too busy frobnicating this gonkulator, I'd like to see a
>> little more discussion of what kind of performance people are
>> expecting from sync rep.  Sounds to me like the best we can expect
>> here is, on every commit: (a) wait for master fsync to complete, (b)
>> send message to standby, (c) wait for reply for reply from standby
>> indicating that fsync is complete on standby.  Even assuming that the
>> network overhead is minimal, that halves the commit rate.  Are the
>> people who want sync rep OK with that?  Is there any way to do better?
>
> (c) would depend on the synchronization mode the user chooses:
>
>  #1 Wait for WAL to be received by the standby
>  #2 Wait for WAL to be received and flushed by the standby
>  #3 Wait for WAL to be received, flushed and replayed by the standby
>
> (a) would depend on synchronous_commit. Personally I'm interested in
> disabling synchronous_commit on the master and choosing #1 as the sync
> mode. Though this may be very optimistic configuration :)
>
> The point for performance of sync rep is to parallelize (a) and (b)+(c),
> I think. If they are performed in a serial manner, the performance
> overhead on the master would become high.

Right. So we to try to come up with a design that permits that, which
must be robust in the face of any number of crashes on the two
machines, in any order. Until we have that, we're just going around
in circles.

One thought that occurred to me is that if the master and standby were
more tightly coupled, you could recover after a crash by making the
one with the further-advanced WAL position the master, and the other
one the standby. That would get around this problem, though at the
cost of considerable additional complexity. But then if one of the
servers comes up and can't talk to the other, you need some mechanism
for preventing split-brain syndrome.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company