On Mon, Dec 26, 2011 at 5:18 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> 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.
Yes exactly.
> 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).
You are right an enum makes much more sense, and the patch would be
much smaller as well so I’ll rework that bit.
/A
