Re: Issues with Quorum Commit

> Heikki had argued that a use case existed where Y out of Y (i.e. all)
> nodes must acknowledge before we commit. That was the use case that
> required us to have standby registration. It was optional in all other
> cases.

Yeah, Y of Y is just a special case of X of Y. And, IMHO, rather
pointless if we can't guarantee consistency between the standbys, which
we can't.

> We should note that Oracle only allows X=1, i.e. first acknowledgement
> releases waiter. My patch provides X=1 only and takes advantage of the
> simpler in-memory data structures as a result.

I agree that we ought to start with X=1 for 9.1 and leave more
complicated architectures until we have that committed and tested.

> You would also be able to specifically release all/some transactions
> from wait state with a simple function pg_cancel_sync_wait() (or similar
> name).

That would be fine for the use cases I'll be implementing.

> My patch does not require a restart of the master to add/remove sync rep
> nodes. They just come and go as needed.
>
> I don't think Fujii's patch would have a great problem with that either,
> but I can't speak for that with precision.

Ok. That really was not made clear in prior arguments.

FYI, for the production uses of synch rep I'd specifically be
implementing, what the users would want is:

1) One master, one synch standby, 1-2 asynch standbys
2) Synch rep tries to synch for # seconds.
3) If it fails, it switches the synch standby to asynch and screams
bloody murder somewhere nagios can pick it up.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com