Re: [GENERAL] How to Qualifying or quantify risk of loss in asynchronous replication

2016-03-19 Thread Andrew Sullivan
On Wed, Mar 16, 2016 at 10:40:03PM +0100, otheus uibk wrote: > 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

Re: [GENERAL] How to Qualifying or quantify risk of loss in asynchronous replication

2016-03-19 Thread otheus uibk
On Wednesday, March 16, 2016, Thomas Munro wrote: > In asynchronous replication, the primary writes to the WAL and flushes the disk. Then, for any standbys that happen to be connected, a WAL sender process trundles along behind feeding new WAL doesn the socket as

Re: [GENERAL] How to Qualifying or quantify risk of loss in asynchronous replication

2016-03-19 Thread Adrian Klaver
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.

Re: [GENERAL] How to Qualifying or quantify risk of loss in asynchronous replication

2016-03-16 Thread Thomas Munro
On Wed, Mar 16, 2016 at 9:59 PM, otheus uibk wrote: >> In asynchronous replication, >> the primary writes to the WAL and flushes the disk. Then, for any >> standbys that happen to be connected, a WAL sender process trundles >> along behind feeding new WAL doesn the socket

Re: [GENERAL] How to Qualifying or quantify risk of loss in asynchronous replication

2016-03-16 Thread otheus uibk
Apologies for the double-reply... This is to point out the ambiguity between the example you gave and stated documentation. On Wednesday, March 16, 2016, Thomas Munro wrote: > > Waiting for the transaction to be durably stored (flushed to disk) on > two servers

Re: [GENERAL] How to Qualifying or quantify risk of loss in asynchronous replication

2016-03-16 Thread otheus uibk
Thomas, thanks for your input... But I'm not quite getting the answer I need > But what precisely is the algorithm and timing involved with streaming > WALs? > > > > Is it: > > * client issues COMMIT > > * master receives commit > > * master processes transaction internally > > *

Re: [GENERAL] How to Qualifying or quantify risk of loss in asynchronous replication

2016-03-15 Thread Thomas Munro
On Wed, Mar 16, 2016 at 6:26 AM, otheus uibk wrote: > I've been working with PG 9.1.8 for two years now, mainly asynchronous > replication. Recently, an IT admin of another group contested that the PG's > asynchronous replication can result in loss of data in a 1-node