Ivan Voras wrote:
Ok, but I imagine there should be a difference between COMMITs
returning before or after the actual data is sent over the network
(though admittedly socket buffering could make it hard to
distinguish).
To be clear here: there is no direct connection whatsoever between the
clients doing commits and the transmission to the standby in 9.0. They
are completely decoupled from one another, done by separate processes.
The client doing the commit has no idea what's the WAL sender process
will do later in order to replicate its results.
In addition to that, how about a compromise: COMMITs returning when
the remote side ACKs acceptance but before it passes data to storage
This is what's referred to as semi-synchronous replication, a term
popularized by its implementation in MySQL:
http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplicationDesign
http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
The planned design for PostgreSQL 9.1:
http://wiki.postgresql.org/wiki/Streaming_Replication
Breaks the possibilities down into four levels:
async: Current model, never wait for the standby
recv: Wait for the standby to receive the data into memory (AKA
semi-synchronous)
fsync: The standby must have committed the data to disk such that it
won't be lost in case of a crash (AKA synchronous)
apply: That data must actually be fully processed and available for
queries against the standby
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@xxxxxxxxxxxxxxx www.2ndQuadrant.us
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
