On 2014-06-05 19:13:34 +0900, furuyao@pm.nttdata.co.jp wrote:
> > -----Original Message-----
> > Hi,
> >
> > On 2014-06-05 17:09:44 +0900, furuyao@pm.nttdata.co.jp wrote:
> > > Synchronous(synchronous_commit = on) mode offers the ability to
> > confirm WAL have been streamed in the same way as synchronous
> > replication.
> > > If an output is used as a different disk from the directory where the
> > transaction log should be stored.
> > > Prevent the loss of data due to disk failure.
> > >
> > > the additional parameter(-m) and replicationslot specify, that its
> > synchronous mode.
> > > All received WAL write after, flush is executed and reply flush
> > > position.
> >
> > What's the usecase for this? I can see some benefit in easier testing
> > of syncrep, but that's basically it?
>
> When used with syncrep, standby server crashes, multiplexing of WAL can be collateral.
> Data loss can be to nearly zero.
I don't see how this gets pg_receivexlog much closer to a solution for
multiplexing WAL. Since there's no support for streaming data, removing
old WAL and such it seems to me you'd need to have something entirely
different anyway?
I'm not really averse to adding this feature (on the basis of easier
syncrep testing alone), but I don't like the arguments for it so far...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services