Hello,
we have a strange (at least to me) deadlock situation which does not seem to
fall into the "usual" deadlock category.
The error as reported in the Postgres log file is this:
2016-03-12 13:51:29.305 CET [23912]: [1-1] user=arthur,db=prod,app=[unknown]
ERROR: deadlock detected
2016-03-1
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
>
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
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
