> From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Daniel Farina
> Sent: Tuesday, July 10, 2012 11:42 AM
>>On Mon, Jul 9, 2012 at 1:30 PM, Shaun Thomas <sthomas@optionshouse.com>
wrote:
>>
>> 1. Slave wants to be synchronous with master. Master wants replication on
at least one slave. They have this, and are happy.
>> 2. For whatever reason, slave crashes or becomes unavailable.
>> 3. Master notices no more slaves are available, and operates in
standalone mode, accumulating WAL files until a suitable slave appears.
>> 4. Slave finishes rebooting/rebuilding/upgrading/whatever, and
re-subscribes to the feed.
>> 5. Slave stays in degraded sync (asynchronous) mode until it is caught
up, and then switches to synchronous. This makes both master and slave
happy, because *intent* of synchronous replication is fulfilled.
>>
> So if I get this straight, what you are saying is "be asynchronous
> replication unless someone is around, in which case be synchronous" is
> the mode you want. I think if your goal is zero-transaction loss then
> you would want to rethink this, and that was the goal of SR: two
> copies, no matter what, before COMMIT returns from the primary.
For such cases, can there be a way with which an option can be provided to
user if he wants to change mode to async?
