Re: pg_receivexlog add synchronous mode

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: furuyao(at)pm(dot)nttdata(dot)co(dot)jp
Cc: pgsql-hackers(at)postgresql(dot)org, teranishih(at)nttdata(dot)co(dot)jp
Subject: Re: pg_receivexlog add synchronous mode
Date: 2014-06-05 08:42:53
Message-ID: 20140605084253.GE2789@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

> 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...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-06-05 08:43:30 Re: Scaling shared buffer eviction
Previous Message Andres Freund 2014-06-05 08:37:35 Re: Need to backpatch 2985e16 to 9.3 and further (HS regression test out)