Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
| От | Bruce Momjian |
|---|---|
| Тема | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ |
| Дата | |
| Msg-id | 201012230149.oBN1nHs17239@momjian.us обсуждение исходный текст |
| Ответ на | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [PATCH] Revert default wal_sync_method to fdatasync
on Linux 2.6.33+
|
| Список | pgsql-hackers |
Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: > > 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. > > Whether it's complex or not isn't really the issue. The issue is that > what test_fsync is testing had better match what the backend does, or > people will be making choices based on not-comparable test results. > I think we should have test_fsync just automatically fold in O_DIRECT > the same way the backend does. The problem is that O_DIRECT was not implemented in macros but rather down in the code: if (!XLogIsNeeded() && !am_walreceiver) o_direct_flag = PG_O_DIRECT; Which means if we just export the macros, we would still not have caught this. I would like to share all the defines --- I am just saying it isn't trivial. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: