Fujii Masao wrote: > On Wed, Feb 17, 2010 at 6:00 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >> On Wed, Feb 17, 2010 at 4:07 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >>> On Wed, Feb 17, 2010 at 3:03 PM, Magnus Hagander <mag...@hagander.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? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
