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