Re: Synchronous replication

On Sun, Aug 1, 2010 at 8:30 AM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Sun, Aug 1, 2010 at 7:11 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> In fact, it's possible for one standby to sync up to X, then disconnect and
>> reconnect, and have the master count it second time in the quorum.
>> Especially if the master doesn't notice that the standby disconnected, e.g a
>> network problem.
>>
>> I don't think any of this quorum stuff makes much sense without explicitly
>> registering standbys in the master.
>
> This doesn't have to be done manually. The streaming protocol could
> include the standby sending its system id to the master. The master
> could just keep a list of system ids with the last record they've been
> sent and the last they've confirmed receipt, fsync, application,
> whatever the protocol covers. If the same system reconnects it just
> overwrites the existing data for that system id.

That seems entirely too clever. Where are you going to store this
data? What if you want to clean out the list?

I've felt from the beginning that the idea of doing synchronous
replication without having an explicit notion of what standbys are out
there was not on very sound footing, and I think the difficulties of
making quorum commit work properly are only further evidence of that.
Much has been made of the notion of "wait for N votes, but allow
standbys to explicitly give up their vote", but that's still not fully
general - for example, you can't implement A && (B || C).

Perhaps someone will claim that nobody wants to do that anyway (which
I don't believe, BTW), but even in simpler cases it would be nicer to
have an explicit policy rather than - in effect - inferring a policy
from a soup of GUC settings. For example, if you want one synchronous
standby (A) and two asynchronous standbys (B and C). You can say
quorum=1 on the master and then configure vote=1 on A and vote=0 on B
and C, but now you have to look at four machines to figure out what
the policy is, and a change on any one of those machines can break it.
ISTM that if you can just write synchronous_standbys=A on the master,
that's a whole lot more clear and less error-prone.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company