> I certainly agree to using such terms. Unfortunately, in my experience,
> synchronous replication is commonly used to mean that transactions are
> guaranteed to be immediately visible on remote nodes after the client
> got commit acknowledgment. That's the cause for confusion I'm envisioning.
I think that's a very important point. It's very possible that 8.4
may support both this feature and Hot Standby (although the latter
seems to have stalled a bit...). That makes me think "oh, great, I
can offload any subset of my read-only queries to the standby". Not
so fast.
I think we need to reserve the term "synchronous replication" for a
system where transactions that begin at the same time on the primary
and standby see the same tuples. Clearly that is "more" synchronous
than what is being proposed here; if we call this "synchronous
replication", what will we call that? "Really Synchronous, Honest, No
Kidding"? Admittedly, we may never implement that feature, but that
seems irrelevant.
It would be useful to have names for all the different possibilities.Random ideas:
Log Shipping. After each log switch, the previous WAL log is copied
to the standby in its entirety.
WAL Streaming - Asynchronous. The WAL log is streamed from master to
standby as it is written, but transactions on the master never wait.
WAL Streaming - Synchronous Receive. The WAL log is streamed from
master to standby as it is written, and transactions on the master
wait until the standby acknowledges receipt of the WAL.
WAL Streaming - Synchronous Write. The WAL log is streamed from
master to standby as it is written, and transactions on the master
wait until the standby acknowledges that the WAL has been written to
disk.
WAL Streaming - Synchronous Apply. The WAL log is streamed from
master to standby as it is written, and transactions on the master
wait until the standby acknowledges that WAL has been written to disk
and applied.
...Robert
