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

On 06.10.2010 19:26, Greg Smith wrote:
> Now, the more relevant question, what I actually need in order for a
> Sync Rep feature in 9.1 to be useful to the people who want it most I
> talk to. That would be a simple to configure setup where I list a subset
> of "important" nodes, and the appropriate acknowledgement level I want
> to hear from one of them. And when one of those nodes gives that
> acknowledgement, commit on the master happens too. That's it. For use
> cases like the commonly discussed "two local/two remote" situation, the
> two remote ones would be listed as the important ones.

This feels like the best way forward to me. It gives some flexibility,
and doesn't need a new config file.

Let me check that I got this right, and add some details to make it more
concrete: Each standby is given a name. It can be something like
"boston1" or "testserver". It does *not* have to be unique across all
standby servers. In the master, you have a list of important,
synchronous, nodes that must acknowledge each commit before it is
acknowledged to the client.

The standby name is a GUC in the standby's configuration file:

standby_name='bostonserver'

The list of important nodes is also a GUC, in the master's configuration
file:

synchronous_standbys='bostonserver, oxfordserver'

To configure for a simple setup with a master and one synchronous
standby (which is not a very good setup from availability point of view,
as discussed to death), you give the standby a name, and put the same
name in synchronous_standbys in the master.

To configure a setup with a master and two standbys, so that a commit is
acknowledged to client as soon as either one of the standbys acknowledge
it, you give both standbys the same name, and the same name in
synchronous_standbys list in the master. This is the configuration that
gives zero data loss in case one server fails, but also caters for
availability because you don't need to halt the master if one standby fails.

To configure a setup with a master and two standbys, so that a commit is
acknowledged to client after *both* standbys acknowledge it, you give
both standbys a different name, and list both names in
synchronous_standbys_list in the master.

I believe this will bend to most real life scenarios people have.

Now, the other big fight is over "wait forever" vs "timeout".
Personally, I'm stand firmly in the "wait forever" camp - you're nuts if
you want a timeout. However, I can see that not everyone agrees :-).
Fortunately, once we have robust "wait forever" behavior, it shouldn't
be hard at all to add a timeout option on top of that, for those who
want it. We should be able to have both options in 9.1.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com