Re: Allowing WAL fsync to be done via O_SYNC
От | Peter Eisentraut |
---|---|
Тема | Re: Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | Pine.LNX.4.30.0103152226410.826-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Allowing WAL fsync to be done via O_SYNC (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Allowing WAL fsync to be done via O_SYNC
Re: Allowing WAL fsync to be done via O_SYNC |
Список | pgsql-hackers |
Tom Lane writes: > "Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes: > > ... I would either > > use fsync as default or don't deal with O_SYNC at all. > > But if O_DSYNC is defined and O_DSYNC != O_SYNC then we should > > use O_DSYNC by default. > > Hm. We could do that reasonably painlessly as a compile-time test in > xlog.c, but I'm not clear on how it would play out as a GUC option. > Peter, what do you think about configuration-dependent defaults for > GUC variables? We have plenty of those already, but we should avoid a variable whose specification is: "The default is 'on' if your system defines one of the macros O_SYNC, O_DSYNC, O_FSYNC, and if O_SYNC and O_DSYNC are distinct, otherwise the default is 'off'." The net result of this would be that the average user would have absolutely no clue what the default on his machine is. Additionally consider that maybe O_SYNC and O_DSYNC have different values but the kernel treats them the same anyway. We really shouldn't try to guess that far. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: