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

Re: [HACKERS] O_DIRECT for WAL writes

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] O_DIRECT for WAL writes
Date: 2005-07-27 05:50:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Thanks for reviewing!
But the patch does not work on HEAD, because of the changes in BootStrapXLOG().
I send the patch with a fix for it.

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:

> If you are doing fsync(), I don't see how O_DIRECT
> makes any sense because O_DIRECT is writing to disk on every write, and
> then what is the fsync() actually doing.

It's depends on OSes. Manpage of Linux says,
    File I/O is done directly to/from user space buffers. The I/O is
    synchronous, i.e., at the completion of the read(2) or write(2) system
    call, data is **guaranteed to have been transferred**.
But manpage of FreeBSD says,
    O_DIRECT may be used to minimize or eliminate the cache effects of read-
    ing and writing.  The system will attempt to avoid caching the data you
    read or write.  If it cannot avoid caching the data,
    it will **minimize the impact the data has on the cache**.

In my understanding, the completion of write() with O_DIRECT does not always
assure an actual write. So there may be difference between O_DIRECT+O_SYNC
and O_DIRECT+fsync(), but I think that is not very often.

> What I did was to add O_DIRECT unconditionally for all uses of O_SYNC
> and O_DSYNC, so it is automatically used in those cases.  And of course,
> if your operating system doens't support O_DIRECT, it isn't used.

I agree with your way, where O_DIRECT is automatically used. 
I bet the combination of O_DIRECT and O_SYNC is always better than
the case O_SYNC only used.

ITAGAKI Takahiro
NTT Cyber Space Laboratories

Attachment: xlog.c.diff
Description: application/octet-stream (12.8 KB)

In response to


pgsql-hackers by date

Next:From: Michael FuhrDate: 2005-07-27 06:12:41
Subject: Re: RESULT_OID Bug
Previous:From: Chris TraversDate: 2005-07-27 05:39:37
Subject: Re: [HACKERS] Enticing interns to PostgreSQL

pgsql-patches by date

Next:From: ITAGAKI TakahiroDate: 2005-07-27 07:35:23
Subject: Unused MMCacheLock
Previous:From: Neil ConwayDate: 2005-07-27 05:16:34
Subject: Re: pg_dump: fix crash on error

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