Re: We really ought to do something about O_DIRECT and data=journalled on ext4

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-12-02T23:58:36Z
Lists: pgsql-hackers
Andrew Dunstan wrote:
> 
> 
> On 11/30/2010 11:17 PM, Tom Lane wrote:
> > Andrew Dunstan<andrew@dunslane.net>  writes:
> >> On 11/30/2010 10:09 PM, Tom Lane wrote:
> >>> We should wait for the outcome of the discussion about whether to change
> >>> the default wal_sync_method before worrying about this.
> >> we've just had a significant PGX customer encounter this with the latest
> >> Postgres on Redhat's freshly released flagship product. Presumably the
> >> default wal_sync_method will only change prospectively.
> > I don't think so.  The fact that Linux is changing underneath us is a
> > compelling reason for back-patching a change here.  Our older branches
> > still have to be able to run on modern OS versions.  I'm also fairly
> > unclear on what you think a fix would look like if it's not effectively
> > a change in the default.
> >
> > (Hint: this *will* be changing, one way or another, in Red Hat's version
> > of 8.4, since that's what RH is shipping in RHEL6.)
> >
> > 			
> 
> Well, my initial idea was that if PG_O_DIRECT is non-zero, we should 
> test at startup time if we can use it on the WAL file system and inhibit 
> its use if not.
> 
> Incidentally, I notice it's not used at all in test_fsync.c - should it 
> not be?

test_fsync certainly should be using PG_O_DIRECT in the same places the
backend does.  Once we decide how to handle PG_O_DIRECT, I will modify
test_fsync to match.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +