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+  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Patch BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory