Re: Synchronization levels in SR

On Thu, 2010-05-27 at 20:13 +0900, Fujii Masao wrote:
> On Thu, May 27, 2010 at 7:33 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > On Thu, 2010-05-27 at 19:21 +0900, Fujii Masao wrote:
> >> On Thu, May 27, 2010 at 6:30 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> >> > Would it be easier to have
> >> > this happen in a second pair of processes WALSynchroniser (on primary)
> >> > and WAL Acknowledger (on standby). WALAcknowledger would send back a
> >> > stream of ack messages with latest xlog positions. WALSynchroniser would
> >> > receive these messages and wake up sleeping backends. If we did that
> >> > then there'd be almost no change at all to existing code, just
> >> > additional code and processes for the sync case. Code would be separate
> >> > and there would be no performance concerns either.
> >>
> >> No, this seems to be bad idea. We should not establish extra connection
> >> between servers. That would be a source of trouble.
> >
> > What kind of trouble? You think using an extra connection would cause
> > problems; why?
>
> Because the number of connection failure cases doubles. Likewise, the number
> of process failure cases would double.

Not really. The users wait for just the synchroniser to return not for
two things. Looks to me that other processes are independent of each
other. Very simple.

> >> > If you do choose to make #3 important, then I'd say you need to work out
> >> > how to make WALWriter active as well, so it can perform regular fsyncs,
> >> > rather than having WALReceiver wait across that I/O.
> >>
> >> Yeah, this might be an option for optimization though I'm not sure how
> >> it has good effect.
> >
> > As I said, WALreceiver would not need to wait across fsync...
>
> Right, but walreceiver still needs to wait for WAL flush by walwriter.

Why does it? I just explained a design where that wasn't required.

> If currently WAL flush is the dominant workload for walreceiver,
> only leaving it to walwriter might not have so good effect. I'm not sure
> whether.

If we're not sure, we could check before agreeing a design.

WAL flush will be costly unless you have huge disk cache.

--
Simon Riggs www.2ndQuadrant.com