On Tue, Jul 10, 2012 at 8:42 AM, Amit Kapila <amit.kap...@huawei.com> wrote: >> 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?
You can already change synchronous_standby_names, and do so without a restart. That will change between sync and async just fine on a live system. And you can control that from some external monitor to define your own rules for exactly when it should drop to async mode. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
