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

Hi,

sorry for being late to join that bike-shedding discussion.

On 03/07/2011 05:09 PM, Alvaro Herrera wrote:
> I think these terms are used inconsistenly enough across the industry
> that what would make the most sense would be to use the common term and
> document accurately what we mean by it, rather than relying on some
> external entity's definition, which could change (like wikipedia's).

I absolutely agree to Alvaro here.

The Wikipedia definition seems to only speak about one local and one
remote node. Requiring an ack from "at least one" remote node seems to
cover that.

Not even Wikipedia goes further in their definition and tries to explain
what 'synchronous replication' could mean in case we have more than two
nodes. A somewhat common expectation is, that all nodes would have to
ack. However, with such a requirement a single node failure brings your
cluster to a full stop. So this isn't a practical option.

Google invented the term "semi-syncronous" for something that's
essentially the same that we have, now, I think. However, I full
heartedly hate that term (based on the reasoning that there's no
semi-pregnant, either).

Others (like me) use "synchronous" or (lately rather) "eager" to mean
that only a majority of nodes need to send an ACK. I have to explain
what I mean every time.

In the end, I don't have a strong opinion either way, anymore. I'm
happy to think of the replication between the master and the one standby
that's sending an ACK first as "synchronous". (Even if those may well
be different standbies for different transactions).

Hope to have brought some light into this discussion.

Regards

Markus Wanner