Re: PostgreSQL Synchronous Replication in production

> Here's a few questions. How you answer them will decide whether you
> really want synchronous replication or not:
> 1. The link between servers encounters network congestion
> a. The whole system should slow down.
> Committed transactions should ALWAYS be on
> two geographically separate machines.
> b. An alert should be sent.
> If it's not sorted in 5 mins we'll get someone to look at it.
> 2. Adding more servers[2] to my replication should:
> a. Make the system as a whole slower[3] and reduce uptime
> but increase the safety of committed transactions
> b. Make the system as a whole faster and increase uptime
>
> There are cases where you want (a), but lots where you want (b) and
> monitor the replication lag.
>
>
> [1] For various values of "safely" of course
> [2] In the same mode - adding async slaves doesn't count
> [3] Assuming a reasonable write load of course. Read-only databases
> won't care.
>
> --
> Richard Huxton
> Archonet Ltd
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

Hello,
Thanks for your answer. I find it very interesting that you say that synchronous setups should always be in two geographically separate locations. In this case they are on the same subnet. Adding the lag of committing to two, geographically separate, databases is not feasible for this OLTP application.
I also like your point that "mostly synchronous is just asynchronous." So, responding by switching to asynchronous as a response to slow-down is asynchronous anyway.
Any other comments, or examples, of when synchronous is worth implementing would be greatly appreciated.
Regards,
Colin