> -----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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
