Re: pg_receivexlog add synchronous mode
От | |
---|---|
Тема | Re: pg_receivexlog add synchronous mode |
Дата | |
Msg-id | A9C510524E235E44AE909CD4027AE196BAAA06D7DC@MBX-MSG-SV03.msg.nttdata.co.jp обсуждение исходный текст |
Ответ на | Re: pg_receivexlog add synchronous mode (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: pg_receivexlog add synchronous mode
Re: pg_receivexlog add synchronous mode |
Список | pgsql-hackers |
> -----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
В списке pgsql-hackers по дате отправления: