Skip site navigation (1) Skip section navigation (2)

Re: Streaming replication on win32, still broken

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication on win32, still broken
Date: 2010-02-18 10:01:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/2/18 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
> Fujii Masao wrote:
>> On Thu, Feb 18, 2010 at 5:28 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> If I'm reading the patch correctly, when wal_sync_method is 'open_sync',
>>> walreceiver nevertheless opens the WAL file without the O_DIRECT flag.
>>> When it later flushes it in XLogWalRcvFlush() by issue_xlog_fsync(),
>>> issue_xlog_fsync() will do nothing because it assumes the write() synced
>>> it already. So the data written isn't being forced to disk at all.
>> When 'open_sync' is chosen, the WAL file is opened with O_SYNC or O_FSYNC
>> flag. So I think that write() flushes the data to disk even if O_DIRECT
>> flag is not given. Am I missing something?
> Ah, ok, you're right.

Yes, I believe the difference is that with O_DIRECT it bypasses the
cache completely. Without it, we still sync it out, but it also goes
into the cache.

O_DIRECT helps us when we're not going to read the file again, because
we don't waste cache on it. If we are, which is the case here, it
should be really bad for performance, since we actually have to do a
physical read.

Incidentally, that should also apply to general WAL when archive_mdoe
is on. Do we optimize for that?

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-02-18 10:02:11
Subject: Re: A thought: should we run pgindent now?
Previous:From: Magnus HaganderDate: 2010-02-18 09:58:31
Subject: Re: Streaming replication and unfit messages

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group