Re: Allowing WAL fsync to be done via O_SYNC
От | Tom Lane |
---|---|
Тема | Re: Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | 14465.984680118@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Allowing WAL fsync to be done via O_SYNC (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Allowing WAL fsync to be done via O_SYNC
Re: Allowing WAL fsync to be done via O_SYNC |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > As a general rule, if something can be a run time option, as opposed to a > compile time option, then it should be. At the very least you keep the > installation simple and allow for easier experimenting. I've been mentally working through the code, and see only one reason why it might be necessary to go with a compile-time choice: suppose we see that none of O_DSYNC, O_SYNC, O_FSYNC, [others] are defined? With the compile-time choice it's easy: #define USE_FSYNC_FOR_WAL, and sail on. If it's a GUC variable then we need a way to prevent the GUC option from becoming unset (which would disable the fsync() calls, leaving nothing to replace 'em). Doable, perhaps, but seems kind of ugly ... any thoughts about that? regards, tom lane
В списке pgsql-hackers по дате отправления: