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