Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

On Fri, Mar 18, 2011 at 2:25 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> In the first place, I think that it's complicated to keep those two parameters
> separately. What about merging them to one parameter? What I'm thinking
> is to remove synchronous_replication and to increase the valid values of
> synchronous_commit from on/off to async/local/remote/both. Each value
> works as follows.
>
>    async   = (synchronous_commit = off && synchronous_replication = off)
>    "async" makes a transaction do local WAL flush and replication
> asynchronously.
>
>    local     = (synchronous_commit = on && synchronous_replication = off)
>    "local" makes a transaction wait for only local WAL flush.
>
>    remote = (synchronous_commit = off && synchronous_replication = on)
>    "remote" makes a transaction wait for only replication. Local WAL flush is
>    performed by walwriter. This is useless in 9.1 because we always must
>    wait for local WAL flush when we wait for replication. But in the future,
>    if we'll be able to send WAL before WAL write (i.e., send WAL from
>    wal_buffers), this might become useful. In 9.1, it seems reasonable to
>    remove this value.
>
>    both     = (synchronous_commit = on && synchronous_replication = on)
>    "both" makes a transaction wait for local WAL flush and replication.
>
> Thought?

Well, if we want to make this all use one parameter, the obvious way
to do it that wouldn't break backward compatibility is to remove the
synchronous_replication parameter altogether and let
synchronous_commit take on the values on/local/off, where on means
wait for sync rep if it's enabled (i.e.
synchronous_standby_names!=''&&max_wal_senders>0) or otherwise just
wait for local WAL flush, local means just wait for local WAL flush,
and off means commit asynchronously.

I'm OK with doing it that way if there's consensus on it, but I'm not
eager to break backward compatibility. Simon/Heikki, any opinion on
that approach?

If we don't have consensus on that then I think we should just do what
I proposed above (and Simon agreed to). I am not eager to spend any
longer than necessary hammering this out; I want to get to beta.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company