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

Josh Berkus wrote:
> However, I think we're getting way the heck away from how far we
> really want to go for 9.1. Can I point out to people that synch rep
> is going to involve a fair bit of testing and debugging, and that
> maybe we don't want to try to implement The World's Most Configurable
> Standby Spec as a first step?

I came up with the following initial spec for Most Configurable Standby
Setup Ever recently:

-The state of all available standby systems is exposed via a table-like
interface, probably an SRF.
-As each standby reports back a result, its entry in the table is
updated with what level of commit it has accomplished (recv, fsync, etc.)
-The table-like list of standby states is then passed to a function,
that you could write in SQL or whatever else makes you happy. The
function returns a boolean for whether sufficient commit guarantees have
been met yet. You can make the conditions required as complicated as
you like.
-Once that function returns true, commit on the master. Otherwise
return to waiting for standby responses.

So that's what I actually want here, because all subsets of it proposed
so are way too boring. If you cannot express every possible standby
situation that anyone will ever think of via an arbitrary function hook,
obviously it's not worth building at all.

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.

Until something that simple is committed, tested, debugged, and had some
run-ins with the real world, I have minimal faith that an attempt to
anything more complicated has sufficient information to succeed. And
complete faith that even trying will fail to deliver something for 9.1.
The scope creep that seems to be happening here in the name of "this
will be hard to change so it must be right in the first version" boggles
my mind.

--
Greg Smith, 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us