On 07/01/2015 11:12 PM, Fujii Masao wrote:
> I don't think this is good approach because there can be the case where
> you need to promote even the standby server not having sync flag.
> Please imagine the case where you have sync and async standby servers.
> When the master goes down, the async standby might be ahead of the
> sync one. This is possible in practice. In this case, it might be better to
> promote the async standby instead of sync one. Because the remaining
> sync standby which is behind can easily follow up with new master.
If we're always going to be polling the replicas for furthest ahead,
then why bother implementing quorum synch at all? That's the basic
question I'm asking. What does it buy us that we don't already have?
I'm serious, here. Without any additional information on synch state at
failure time, I would never use quorum synch. If there's someone on
this thread who *would*, let's speak to their use case and then we can
actually get the feature right. Anyone?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
