Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
От | Josh Berkus |
---|---|
Тема | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ |
Дата | |
Msg-id | 4CFD82A2.3040405@agliodbs.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
|
Список | pgsql-hackers |
On 12/5/10 2:12 PM, Greg Smith wrote: > Josh Berkus wrote: >> I modified test_fsync in two ways to run this; first, to make it support >> O_DIRECT, and second to make it run in the *current* directory. > > Patch please? I agree with the latter change; what test_fsync does is > surprising. Attached. Making it support O_DIRECT would be possible but more complex; I don't see the point unless we think we're going to have open_sync_with_odirect as a seperate option. > I suggested a while ago that we refactor test_fsync to use a common set > of source code as the database itself for detecting things related to > wal_sync_method, perhaps just extract that whole set of DEFINE macro > logic to somewhere else. That happened at a bad time in the development > cycle (right before a freeze) and nobody ever got back to the idea > afterwards. If this code is getting touched, and it's clear it is in > some direction, I'd like to see things change so it's not possible for > the two to diverge again afterwards. I don't quite follow you. Maybe nobody else did last time, either. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
Вложения
В списке pgsql-hackers по дате отправления: