On Wed, Mar 2, 2011 at 11:30 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Mar 2, 2011 at 8:22 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> The WALSender deliberately does *not* wake waiting users if the standby
>> disconnects. Doing so would break the whole reason for having sync rep
>> in the first place. What we do is allow a potential standby to takeover
>> the role of sync standby, if one is available. Or the failing standby
>> can reconnect and then release waiters.
>
> If there is potential standby when synchronous standby has gone, I agree
> that it's not good idea to release the waiting backends soon. In this case,
> those backends should wait for next synchronous standby.
>
> On the other hand, if there is no potential standby, I think that the waiting
> backends should not wait for the timeout and should wake up as soon as
> synchronous standby has gone. Otherwise, those backends suspend for
> a long time (i.e., until the timeout expires), which would decrease the
> high-availability, I'm afraid.
>
> Keeping those backends waiting for the failed standby to reconnect is an
> idea. But this looks like the behavior for "allow_standalone_primary = off".
> If allow_standalone_primary = on, it looks more natural to make the
> primary work alone without waiting the timeout.
Also I think that the waiting backends should be released as soon as the
last synchronous standby switches to asynchronous mode. Since there is
no standby which is planning to reconnect, obviously they no longer need
to wait.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
