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
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
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.
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
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
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
> > *
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