Re: Allowing WAL fsync to be done via O_SYNC
От | Bruce Momjian |
---|---|
Тема | Re: Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | 200103152046.PAA18820@candle.pha.pa.us обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I later read Vadim's comment that fsync() of two blocks may be faster > > than two O_* writes, so I am now confused about the proper solution. > > However, I think we need to pick one and make it invisible to the user. > > Perhaps a compiler/config.h flag for testing would be a good solution. > > I believe that we don't know enough yet to nail down a hard-wired > decision. Vadim's idea of preferring O_DSYNC if it appears to be > different from O_SYNC is a good first cut, but I think we'd better make > it possible to override that, at least for testing purposes. > > So I think it should be configurable at *some* level. I don't much care > whether it's a config.h entry or a GUC variable. > > But consider this: we'll be more likely to get some feedback from the > field (allowing us to refine the policy in future releases) if it is a > GUC variable. Not many people will build two versions of the software, > but people might take the trouble to play with a run-time configuration > setting. Yes, I can imagine. Can we remove it once we know the answer? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: