On Mon, 2011-12-26 at 16:23 +0100, Magnus Hagander wrote:
> On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
> <alex.bjornhagen@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
