On Feb20, 2011, at 08:12 , Jaime Casanova wrote:
> considering that synchronous_replication to on means that we *want*
> durability, and that synchronous_commit to off means we don't *care*
> about durability. Then the real question here is: in the presence of
> synchronous_replication to on (which means we want durability), are we
> allowed to assume we can loss data?
From the angle, shouldn't we turn synchronous_replication=on into a third
possible state of synchronous_commit?
We'd then have
synchronous_commit=off #Same as now
synchronous_commit=local #Same as synchronous_commit=on, #synchronous_replication=off
synchronous_commit=standby #Same as synchronous_commit=on, #synchronous_replication=on
> one way to manage that is simply disallow that combination with an
> error, maybe that is a bit strict but we haven't to make assumptions;
> the other option is to keep safe which means keep durability so if you
> want to risk some data then you should disable synchronous_replication
> as well as synchronous_commit... maybe sending a message to the log
> when you detect the conflicting situation.
The question is where we'd raise the error, though. Doing it on GUC
assignment makes the behaviour depend on assignment order. That's a
bad idea I believe, since it possibly breaks ALTER ROLE/DATEBASE SET ....
best regards,
Florian Pflug