Heikki,
> The master can not roll back or cancel the transaction. That's
> completely infeasible, the WAL record has been written to local disk
> already. The best it can do is halt and wait for enough standbys to
> appear to fulfill the quorum. The client will hang waiting for the
> COMMIT to finish, and the transaction will appear as in-progress to
> other transactions.
Ohhh. Good point. So there's no real point in a timeout setting for
quorum commit; it's always "wait forever".
So, this is a critical issue with "wait forever" even with one server.
> There's subtle point here that I don't think has been discussed yet: If
> the master is forcibly restarted at that point, with pg_ctl restart -m
> immediate, strictly speaking the master should start up in the same
> state, with the unlucky transaction still appearing as in-progress,
> until the standby acknowledges.
Yeah. That makes the ability to issue a command which says "drop all
synch rep and commit whatever's pending" to be critical.
However, this makes for, in some ways, a worse situation: if you fail to
achieve quorum on any commit, then you need to rebuild your entire
quorum pool from scratch.
> You start a new one from the latest base backup and let it catch up?
> Possibly modifying the config file in the master to let it know about
> the new standby, if we go down that path. This part doesn't seem
> particularly hard to me.
Yeah? How do you modify the config file and get the master to consider
the new server to be part of the quorum pool *without restarting the
master*?
Again, I'm just saying that merely doing single-server synch rep, *and*
making HS/SR easier to admin in general, is going to be a big task for
9.1. Quorum Commit needs to be considered a separate feature, and one
which is dispensible for 9.1.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
