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

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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: We really ought to do something about O_DIRECT and data=journalled on ext4
Date: 2010-12-01 14:00:13
Message-ID: 4CF654ED.2010806@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

On 11/30/2010 11:17 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)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?

cheers

andrew



In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-12-01 14:03:15
Subject: Re: directory archive format for pg_dump
Previous:From: Radosław SmoguraDate: 2010-12-01 13:59:39
Subject: Re: [HACKERS] Improved JDBC driver part 2

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