Allowing WAL fsync to be done via O_SYNC
От | Tom Lane |
---|---|
Тема | Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | 14309.984677392@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Allowing WAL fsync to be done via O_SYNC
Re: Allowing WAL fsync to be done via O_SYNC Re: Allowing WAL fsync to be done via O_SYNC Re: Allowing WAL fsync to be done via O_SYNC |
Список | pgsql-hackers |
Based on the tests we did last week, it seems clear than on many platforms it's a win to sync the WAL log by writing it with open() option O_SYNC (or O_DSYNC where available) rather than issuing explicit fsync() (resp. fdatasync()) calls. In theory fsync ought to be faster, but it seems that too many kernels have inefficient implementations of fsync. I think we need to make both O_SYNC and fsync() choices available in 7.1. Two important questions need to be settled: 1. Is a compile-time flag (in config.h.in) good enough, or do we need to make it configurable via a GUC variable? (A variable would have to be postmaster-start-time changeable only, so you'd still need a postmaster restart to change it.) 2. Which way should be the default? There's also the lesser question of what to call the config symbol or variable. My inclination is to go with a compile-time flag named USE_FSYNC_FOR_WAL and have the default be off (ie, use O_SYNC by default) but I'm not strongly set on that. Opinions anyone? In any case the code should automatically prefer O_DSYNC over O_SYNC if available, and should prefer fdatasync() over fsync() if available; I doubt we need to provide a knob to alter those choices. BTW, are there any platforms where O_DSYNC exists but has a different spelling? regards, tom lane
В списке pgsql-hackers по дате отправления: