Re: Streaming Replication patch for CommitFest 2009-09 - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Streaming Replication patch for CommitFest 2009-09
Date
Msg-id 4ABB5212.9050002@enterprisedb.com
Whole thread Raw
In response to Re: Streaming Replication patch for CommitFest 2009-09  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Fujii Masao wrote:
> On Thu, Sep 24, 2009 at 7:41 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Fujii Masao wrote:
>>> In the 'replication-orig' branch, walreceiver fsyncs the previous XLOG
>>> file after receiving new XLOG records before writing them. This would
>>> increase the backend's waiting time for replication in synchronous case.
>>> The walreceiver should fsync the XLOG file after sending ACK (if needed)
>>> before receiving the next XLOG records?
>> I don't follow. Wareceiver does fsync the file just after writing it if
>>  the fsync_requested flag was set in the message. Surely that would be
>> set in synchronous mode, that's what the flag is for, right?
> 
> That's the case where fsync is issued at the end of segment.
> In this case, since the fsync_requested flag is not set,
> walreceiver doesn't perform fsync in that loop. After the
> next XLOG arrives, walreceiver does fsync to the previous file,
> in XLogWalRcvWrite().

Ok. I don't see anything wrong with that. If the primary didn't set
fsync_requested, it's not in a hurry to get an acknowledgment.

I guess we could check *after* writing, if we just finished filling the
segment. If we did, we could fsync since we're going to fsync anyway as
soon as we receive the next message. Not sure if it's worth the trouble.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Streaming Replication patch for CommitFest 2009-09
Next
From: Petr Jelinek
Date:
Subject: Re: [PATCH] DefaultACLs