Hi,
Josh Berkus wrote:
> Peter Eisentraut wrote:
>> It's the color of the bikeshed ...
Agreed. It's why I've decided to support various modes for Postgres-R.
I'm glad to see that the current "Sync Rep" approach does the same.
> Hmmm. I thought this was pretty clear. There's three levels of synch
> which are useful features:
>
> 1) "synchronus" standby which is really asynchronous, but only has a gap
> of < 100ms.
A synchronous standby which is really asynchronous? That's exactly the
naming challenge I've been pointing to.
Commonly used terms are: "virtually synchronous", "approximately
synchronous", "near-real-time replication" or "eager replication", but
for most users, this is not "synchronous" (enough).
(BTW: there's no such "< 100 ms" guarantee. It may be typically below
100 ms, or even below 10 ms on average. But replication is not about the
typical or average case. It's much more about failures and uncommon
cases. The guarantee you can get in such a system (by declaring a node
as dead) is much more likely to be within the range of several seconds
and more, be it network, disk or whatever other failure-timeout that
applies here.)
> 2) Synchronous standby which guarentees that all committed transactions
> are on the failover node and that no data will be lost for failover, but
> the failover node is still in standby mode.
What's the difference to 1) here? I'm not following.
> 3) Synchronous replication where the standby node has identical
> transactions to the master node, and is queryable read-only.
So, a synchronous standby is different from synchronous replication in
that it's asynchronous?
Sorry for bugging with naming, but I think it is important for an
understanding during development.
> Any of these levels would be useful and allow a certain number of our
> users to deploy PostgreSQL in an environment where it wasn't used
> before.
I absolutely agree to that statement.
However, please do not confuse future users (and today's hackers), but
instead use existing terms consistently and clearly. Something that lags
behind, potentially by several seconds (in case of failure) is commonly
considered asynchronous, no matter how close to "immediate" it is on
average.
Regards
Markus Wanner
