Re: Standalone synchronous master

> On 01/11/2014 08:52 PM, Amit Kapila wrote:> It is better than async mode
> in a way such that in async mode it never
>> waits for commits to be written to standby, but in this new mode it will
>> do so unless it is not possible (all sync standby's goes down).
>> Can't we use existing wal_sender_timeout, or even if user expects a
>> different timeout because for this new mode, he expects master to wait
>> more before it start operating like standalone sync master, we can provide
>> a new parameter.
>
> One of the reasons that there's so much disagreement about this feature
> is that most of the folks strongly in favor of auto-degrade are thinking
> *only* of the case that the standby is completely down. There are many
> other reasons for a sync transaction to hang, and the walsender has
> absolutely no way of knowing which is the case. For example:
>
> * Transient network issues
> * Standby can't keep up with master
> * Postgres bug
> * Storage/IO issues (think EBS)
> * Standby is restarting
>
> You don't want to handle all of those issues the same way as far as sync
> rep is concerned. For example, if the standby is restaring, you
> probably want to wait instead of degrading.

I think it might be difficult to differentiate the cases except may be
by having a separate timeout for this mode, so that it can wait more
when server runs in this mode. OTOH why can't we define this new
mode such that it will behave same for all cases, basically we can tell
whenever sync standby is not available (n/w issue or m/c down), it will
behave as master in async mode.
Here I think the important point would be to gracefully allow resuming
sync standby when it tries to reconnect (we can allow to reconnect if it
can resolve all WAL differences.)

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com