> -----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.
> > Flush is not performed every time write, it is performed collectively
> > like walrecever.
>
> I only glanced at this, but afaics you're only flushing at the end every
> WAL segment. That will result in absolutely horrible performance, right?
> Walreceiver does flush more frequently than that. It basically syncs
> every chunk of received WAL...
IMO the completion of the write loop was completion of received WAL.
And Walreceiver same.
I confirm it about the flush position.
Regards,
--
Furuya Osamu
