Re: We really ought to do something about O_DIRECT and data=journalled on ext4
От | Andrew Dunstan |
---|---|
Тема | Re: We really ought to do something about O_DIRECT and data=journalled on ext4 |
Дата | |
Msg-id | 4CF654ED.2010806@dunslane.net обсуждение исходный текст |
Ответ на | Re: We really ought to do something about O_DIRECT and data=journalled on ext4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: We really ought to do something about O_DIRECT
and data=journalled on ext4
|
Список | pgsql-hackers |
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? cheers andrew
В списке pgsql-hackers по дате отправления: