On Wed, Mar 16, 2016 at 11:51 PM, Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
Perhaps "Clarity is in the eye of the beholder". If you are very familiar with the internals and operation of the software, the documentation is clear. It's like hindsight; it's always "20/20".
Asynchronous to what? The next sentence indicates the delay is relevant to *becoming visible in the standby*. Thus, a message could be received by the standby, but before it is logged to disk, both it and the primary fail. Meanwhile, the client thinks its transaction was committed, but in fact, it was committed to only one side. Thus, it does NOT necessarily imply that "asynchronous" means with respect to the client receiving "transaction complete" acknowledgement.
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. ..."
That refers to *log shipping* not streaming.
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. ..."
Asynchronous to what? The next sentence indicates the delay is relevant to *becoming visible in the standby*. Thus, a message could be received by the standby, but before it is logged to disk, both it and the primary fail. Meanwhile, the client thinks its transaction was committed, but in fact, it was committed to only one side. Thus, it does NOT necessarily imply that "asynchronous" means with respect to the client receiving "transaction complete" acknowledgement.
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. "
Again, an asynchronous mode *could mean* that the WALs are sent before the commit was acknowledge, and that would be consistent with the above statements.
