Re: pg_receivexlog add synchronous mode

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

In response to

Responses

Browse pgsql-hackers by date

  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?