Hi, On 09/17/2010 01:56 PM, Fujii Masao wrote:
And standby registration is required when we support "wait forever when synchronous standby isn't connected at the moment" option that Heikki explained upthread.
That requirement can be reduced to say that the master only needs to known how many synchronous standbys *should* be connected.
IIUC that's pretty much exactly the quorum_commit GUC that Simon proposed, because it doesn't make sense to have more synchronous standbys connected than quorum_commit (as Simon pointed out downthread).
I'm unsure about what's better, the full list (giving a good overview, but more to configure) or the single sum GUC (being very flexible and closer to how things work internally). But that seems to be a UI question exclusively.
Regarding the "wait forever" option: I don't think continuing is a viable alternative, as it silently ignores the requested level of persistence. The only alternative I can see is to abort with an error. As far as comparison is allowed, that's what Postgres-R currently does if there's no majority of nodes. It allows to emit an error message and helpful hints, as opposed to letting the admin figure out what and where it's hanging. Not throwing false errors has the same requirements as "waiting forever", so that's an orthogonal issue, IMO.
Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
