> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@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 <stho...@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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
