Re: Standalone synchronous master - Mailing list pgsql-hackers

Josh Berkus <josh@agliodbs.com> 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.

+1

> 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
persistingthe work of the transaction on both the (local) primary and a synchronous replica should issue a WARNING. 
Thatsaid, the API for some connectors (like JDBC) puts the burden on the application or its framework to check for
warningseach time and do something reasonable if found; I fear that a Venn diagram of those shops which would use this
newfeature 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.

+1

Since this new feature, where enabled, would cause synchronous replication to provide no guarantees beyond what
asynchronousreplication 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
EDB: http://www.enterprisedb.com
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
tothe moment of primary failure, the feature improves the odds (versus async) that successfully committed transactions
willnot 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
ifthe last sync standby has failed, read only for some interval and then read write with this feature or if there is
stillanother working sync rep target, all transactions without interruption with async.