On Mon, 2011-12-26 at 16:23 +0100, Magnus Hagander wrote: > On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen > <alex.bjornha...@gmail.com> wrote: > >>>> Basically I like this whole idea, but I'd like to know why do you think > >>>> this functionality is required? > > > >>> How should a synchronous master handle the situation where all > >>> standbys have failed ? > >>> > >>> Well, I think this is one of those cases where you could argue either > >>> way. Someone caring more about high availability of the system will > >>> want to let the master continue and just raise an alert to the > >>> operators. Someone looking for an absolute guarantee of data > >>> replication will say otherwise. > > > >>If you don't care about the absolute guarantee of data, why not just > >>use async replication? It's still going to replicate the data over to > >>the client as quickly as it can - which in the end is the same level > >>of guarantee that you get with this switch set, isn't it? > > > > This setup does still guarantee that if the master fails, then you can > > still fail over to the standby without any possible data loss because > > all data is synchronously replicated. > > Only if you didn't have a network hitch, or if your slave was down. > > Which basically means it doesn't *guarantee* it. >
It doesn't guarantee it, but it increases the master availability. That's the kind of customization some users would like to have. Though I find it weird to introduce another GUC there. Why not add a new enum value to synchronous_commit, such as local_only_if_slaves_unavailable (yeah, the enum value is completely stupid, but you get my point). -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com PostgreSQL Sessions #3: http://www.postgresql-sessions.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
