On 03/16/2016 02:40 PM, otheus uibk wrote:
> On Wednesday, March 16, 2016, Thomas Munro
>
> Somehow, the documentation misleads (me) to believe the async
> replication algorithm at least guarantees WAL records are *sent* before
> responding "committed" to the client. I now know this is not the case.
> *grumble*.
>
> How can I help make the documentation clearer on this point?
I thought it was already clear:
http://www.postgresql.org/docs/9.4/interactive/warm-standby.html
"It should be noted that log shipping is asynchronous, i.e., the WAL
records are shipped after transaction commit. As a result, there is a
window for data loss should the primary server suffer a catastrophic
failure; transactions not yet shipped will be lost. ..."
http://www.postgresql.org/docs/9.4/interactive/warm-standby.html#STREAMING-REPLICATION
"Streaming replication is asynchronous by default (see Section 25.2.8),
in which case there is a small delay between committing a transaction in
the primary and the changes becoming visible in the standby. This delay
is however much smaller than with file-based log shipping, typically
under one second assuming the standby is powerful enough to keep up with
the load. ..."
http://www.postgresql.org/docs/9.4/interactive/warm-standby.html#SYNCHRONOUS-REPLICATION
"PostgreSQL streaming replication is asynchronous by default. If the
primary server crashes then some transactions that were committed may
not have been replicated to the standby server, causing data loss. The
amount of data loss is proportional to the replication delay at the time
of failover.
Synchronous replication offers the ability to confirm that all changes
made by a transaction have been transferred to one synchronous standby
server. This extends the standard level of durability offered by a
transaction commit. This level of protection is referred to as 2-safe
replication in computer science theory. "
>
> --
> Otheus
> otheus.uibk@gmail.com <mailto:otheus.uibk@gmail.com>
> otheus.shelling@uibk.ac.at <mailto:otheus.shelling@uibk.ac.at>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
