Re: Streaming Replication patch for CommitFest 2009-09

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming Replication patch for CommitFest 2009-09
Date: 2009-09-24 11:03:46
Message-ID: 4ABB5212.9050002@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao wrote:
> On Thu, Sep 24, 2009 at 7:41 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2009-09-24 11:23:03 Re: [PATCH] DefaultACLs
Previous Message Heikki Linnakangas 2009-09-24 10:57:22 Re: Streaming Replication patch for CommitFest 2009-09