> 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,
sothat it can wait more when server runs in this mode. OTOH why can't we define this new mode such that it will
behavesame 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
standbywhen 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