Fujii Masao wrote:
> On Wed, Feb 17, 2010 at 6:00 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Wed, Feb 17, 2010 at 4:07 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> On Wed, Feb 17, 2010 at 3:03 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> In that case, O_DIRECT would be counterproductive, no? It maps to
>>>> FILE_FLAG_NOI_BUFFERING, which makes sure it doesn't go into the
>>>> cache. So the read in the startup proc is actually guaranteed to
>>>> reuqire a physical read - of something we just wrote, so it'll almost
>>>> certainly end up waiting for a rotation, no?
>>>> Seems like getting rid of O_DIRECT here is the right thing to do,
>>>> regardless of this.
>>> Agreed. I'll remove O_DIRECT from walreceiver.
>> Here is the patch to do that.
> Ooops! I found the bug in the patch. Here is the updated version.
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.
How about just forcing sync_method to 'fsync' in walreceiver?
In response to
pgsql-hackers by date
|Next:||From: David E. Wheeler||Date: 2010-02-17 20:50:12|
|Subject: Re: [HACKERS] Listen/Notify payload and interfaces|
|Previous:||From: Tom Lane||Date: 2010-02-17 20:04:50|
|Subject: Re: default parameters |