From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | furuyao(at)pm(dot)nttdata(dot)co(dot)jp |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, teranishih(at)nttdata(dot)co(dot)jp |
Subject: | Re: pg_receivexlog add synchronous mode |
Date: | 2014-06-06 17:14:09 |
Message-ID: | CAHGQGwH2_s+YBSdqCq1p82ZTiPTxktFTDp_baD0H0eRo44FTcg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 6, 2014 at 8:05 PM, <furuyao(at)pm(dot)nttdata(dot)co(dot)jp> wrote:
>> -----Original Message-----
>> > > 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.
> As you say,Walreceiver does flush more frequently than that.
No. IIUC walreceiver does flush *less* frequently than what you implemented
on pg_receivexlog. Your version of pg_receivexlog tries to do flush every time
when it receives one WAL chunk. OTOH, walreceiver does flush only when
there is no extra WAL chunk in receive buffer. IOW, after writing WAL chunk,
if there is another WAL chunk that walreceiver can receive immediately, it
postpones flush later.
> However, it seems difficult to apply as same way.
Why? ISTM that's not so difficult.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-06-06 17:16:56 | Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby |
Previous Message | Tom Lane | 2014-06-06 17:04:29 | Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby |