On Sat, Feb 19, 2011 at 10:52 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Feb 19, 2011 at 3:28 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> First, we should be clear to explain that you are referring to the fact
>> that the request
>> synchronous_commit = off
>> synchronous_replication = on
>> makes no sense in the way the replication system is currently designed,
>> even though it is a wish-list item to make it work in 9.2+
>
> What exactly do you mean by "make it work"? We can either (1) wait
> for the local commit and the remote commit (synchronous_commit=on,
> synchronous_replication=on), (2) wait for the local commit only
> (synchronous_commit=on, synchronous_replication=off), or (3) wait for
> neither (synchronous_commit=off, synchronous_replication=off).
> There's no fourth possible behavior, AFAICS.
>
> The question is whether synchronous_commit=off,
> synchronous_replication=on should behave like (1) or (3); AFAICS
> there's no fourth possible behavior. You have it as #1; I'm arguing
> it should be #3. I realize it's an arguable point; I'm just arguing
> for what makes most sense to me.
>
IMHO, we should stick to the safest option.
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?
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.
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
