On Tue, Jul 10, 2012 at 8:42 AM, Amit Kapila <amit.kapila@huawei.com> wrote:
>> 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?
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
