On Feb21, 2011, at 00:09 , Jaime Casanova wrote:
> 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 ;)
I figured we'd say something like
'To guarantee durability of transactions except in the fail-over case,
set synchronous_commit to "local". To additionally guarantee durability
even in the case of a fail-over to a standby node, set synchronous_commit
to "standby". This causes a COMMIT to only report success once the commit
record has be acknowledged by the current synchronous standby node, and
will therefore induce a higher latency of COMMIT requests.'
Other possible names for the "standby" options that come to mind are
"replication", "replica" or "replicate". Or maybe "cluster", but that
seems confusing since we sometimes call the collection of databases managed
by one postgres instance a cluster.
best regards,
Florian Pflug