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  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Radosław Smogura
Дата:
Сообщение: Re: [JDBC] Improved JDBC driver part 2
Следующее
От: Yeb Havinga
Дата:
Сообщение: FK's to refer to rows in inheritance child