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
