From: | <furuyao(at)pm(dot)nttdata(dot)co(dot)jp> |
---|---|
To: | <andres(at)2ndquadrant(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_receivexlog add synchronous mode |
Date: | 2014-06-05 10:13:34 |
Message-ID: | A9C510524E235E44AE909CD4027AE196BAAA06D7DC@MBX-MSG-SV03.msg.nttdata.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> Hi,
>
> On 2014-06-05 17:09:44 +0900, furuyao(at)pm(dot)nttdata(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Mamin | 2014-06-05 10:18:27 | Re: "pivot aggregation" with a patched intarray |
Previous Message | Heikki Linnakangas | 2014-06-05 09:59:31 | Re: doPickSplit stack buffer overflow in XLogInsert? |