> -----Original Message-----
> Hi,
> On 2014-06-05 17:09:44 +0900, furu...@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 
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.


Furuya Osamu

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to