Re: standby registration (was: is sync rep stalled?)

On Mon, Oct 4, 2010 at 3:25 PM, David Christensen <david@endpoint.com> wrote:
>
> On Oct 4, 2010, at 2:02 PM, Robert Haas wrote:
>
>> On Mon, Oct 4, 2010 at 1:57 PM, Markus Wanner <markus@bluegap.ch> wrote:
>>> On 10/04/2010 05:20 PM, Robert Haas wrote:
>>>> Quorum commit, even with configurable vote weights, can't handle a
>>>> requirement that a particular commit be replicated to (A || B) && (C
>>>> || D).
>>>
>>> Good point.
>>>
>>> Can the proposed standby registration configuration format cover such a
>>> requirement?
>>
>> Well, if you can name the standbys, there's no reason there couldn't
>> be a parameter that takes a string that looks pretty much like the
>> above.  There are, of course, some situations that could be handled
>> more elegantly by quorum commit ("any 3 of 5 available standbys") but
>> the above is more general and not unreasonably longwinded for
>> reasonable numbers of standbys.
>
>
> Is there any benefit to be had from having standby roles instead of individual names?  For instance, you could
integratethis into quorum commit to express 3 of 5 "reporting" standbys, 1 "berlin" standby and 1 "tokyo" standby from
agroup of multiple per data center, or even just utilize role sizes of 1 if you wanted individual standbys to be
"named"in this fashion.  This role could be provided on connect of the standby is more-or-less tangential to the
specificregistration issue. 

It's possible to construct a commit rule that is sufficiently complex
that this can't handle it, but it has to be pretty hairy.  The
simplest example I can think of is A || ((B || C) && (D || E)).  And
you could even handle that if you allow standbys to belong to multiple
roles; in fact, I think you can handle arbitrary Boolean formulas that
way by converting to conjunctive normal form.  The use cases for such
complex formulas are fairly thin, though, so I'm not sure that's a
very compelling argument one way or the other.   I think in the end
this is not much different from standby registration; you still have
registrations, they just represent groups of machines instead of
single machines.

I think from a reporting point of view it's a little nicer to have
individual registrations rather than group registrations.  For
example, you might ask the master which slaves are connected and where
they are in the WAL stream, or something like that, and with
individual standby names that's a bit easier to puzzle out.  Of
course, you could have individual standby names (that are only for
identification) and use groups for everything else.  That's maybe a
bit more complicated (each slave needs to send the master a
name-for-identification and a group) but it's certainly workable.  We
might also in the future have cases where you want to group standbys
in one way for the commit-rule and another way for some other setting,
but I can't think of exactly what other setting you'd be likely to
want to set in a fashion orthogonal from commit rule, and even if we
did think of one, allowing standbys to be members of multiple groups
would solve that problem, too.  That feels a bit more complex to me,
but it's not that likely to happen in practice, so it would probably
be OK.  So I guess I think individual registrations are a bit cleaner
and likely to lead to slightly fewer knobs over the long term, but
group registrations seem like they could be made to work, too.

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