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
failure. After re-readinG the documentation, I cannot determine to what
extent this is t
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 failure.
> After re-readinG t
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
> > * maste
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 before COMMIT returns means that y
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 as soon as it can, but
>
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.
*g
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 soon as
it can, but it can be ru
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 h
On Wed, Mar 16, 2016 at 11:51 PM, Adrian Klaver
wrote:
>
> I thought it was already clear:
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".
> http:
