Re: We really ought to do something about O_DIRECT and data=journalled on ext4
От | Bruce Momjian |
---|---|
Тема | Re: We really ought to do something about O_DIRECT and data=journalled on ext4 |
Дата | |
Msg-id | 201012022358.oB2NwaH24037@momjian.us обсуждение исходный текст |
Ответ на | Re: We really ought to do something about O_DIRECT and data=journalled on ext4 (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: We really ought to do something about O_DIRECT and
data=journalled on ext4
|
Список | 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. +
В списке pgsql-hackers по дате отправления: