Josh Berkus <> wrote:

>>  Add a new parameter :

>>  synchronous_standalone_master = on | off
> I think this is a TERRIBLE name for any such parameter.  What does
> "synchronous standalone" even mean?  A better name for the parameter
> would be "auto_degrade_sync_replication" or 
> "synchronous_timeout_action
> = error | degrade", or something similar.  It would be even better for
> this to be a mode of synchronous_commit, except that synchronous_commit
> is heavily overloaded already.


> a) we should at least send committing clients a WARNING if they have
> commited a synchronous transaction and we are in degraded mode.
> I know others have dismissed this idea as too "talky", but from my
> perspective, the agreement with the client for each synchronous commit
> is being violated, so each and every synchronous commit should report
> failure to sync.  Also, having a warning on every commit would make it
> easier to troubleshoot degraded mode for users who have ignored the
> other warnings we give them.

I agree that every synchronous commit on a master which is configured for 
synchronous replication which returns without persisting the work of the 
transaction on both the (local) primary and a synchronous replica should issue 
a WARNING.  That said, the API for some connectors (like JDBC) puts the burden 
on the application or its framework to check for warnings each time and do 
something reasonable if found; I fear that a Venn diagram of those shops which 
would use this new feature and those shops that don't rigorously look for and 
reasonably deal with warnings would have significant overlap.

> b) pg_stat_replication needs to show degraded mode in some way, or we
> need pg_sync_rep_degraded(), or (ideally) both.


Since this new feature, where enabled, would cause synchronous replication to 
provide no guarantees beyond what asynchronous replication does[1], but would 
tend to cause people to have an *expectation* that they have some additional 
protection, I think proper documentation will be a big challenge.

Kevin Grittner
The Enterprise PostgreSQL Company

[1]  If I understand correctly, this is what the feature is intended to provide:
- A transaction successfully committed on the primary is guaranteed to be 
visible on the replica?  No, in all modes.
- A transaction successfully committed on the primary is guaranteed *not* to be 
visible on the replica?  No, in all modes.
- A the work of a transaction which has not returned from a commit request may 
be visible on the primary and/or the standby?  Yes in all modes.
- A failure of the primary is guaranteed not to lose successfully committed 
transactions when failing over to the replica?  Yes for sync rep without this 
feature, no for async or when this feature is used.  If things are going well 
up to the moment of primary failure, the feature improves the odds (versus 
async) that successfully committed transactions will not be lost, or may reduce 
the number of successfully committed transactions lost.
- A failure of the replica allows transactions on the primary to continue?  
Read only for sync rep without this feature if the last sync standby has 
failed, read only for some interval and then read write with this feature or if 
there is still another working sync rep target, all transactions without 
interruption with async.

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to