Re: Sync Rep v17

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