On Sun, Feb 20, 2011 at 7:20 AM, Florian Pflug <fgp@phlo.org> wrote:
> 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
>
that would be a little confuse and difficult to document. at least i
know that as far as we say something like this "to activate
synchronous replication set synchronous commit to standby" users
somehow will have the impression that locally the commit is
asynchronous (ok, a have had bad experiences with Ecuadorian users ;)
>> 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 ....
>
well, yeah... maybe is just to much worthless work... but we can check
before commit and send a NOTICE message
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
