On Thu, May 27, 2010 at 7:33 PM, Simon Riggs <simon@2ndquadrant.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@2ndquadrant.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.
>> > 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.
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.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
