Using years-old benchmark attached to PostreSQL ML[1], I've observed
tiny bit more than double boost in speed when using fdatasync instead of
traditional fsync, on two Linux machines, each equipped with an SSD.
While the observation may be disputable (there are various
interpretations to what "synchronized I/O" actually means), by logical
extension of what the two are supposed to do, one can expect fdatasync
will perform no worse than fsync. Having the timestamps correct is
really not a priority, compared to timely processing of the message
stream. So let's use it whenever possible with QB_LOG_CONF_FILE_SYNC
requested.
As an aside, PostreSQL seems to be be using "fdatasync" method of
updating out to disk by default on Linux till today[2].
[1] https://www.postgresql.org/message-id/1095055866.414539fadb90d@webmail.rawbw.comhttps://www.postgresql.org/message-id/attachment/20659/syncbench.c
[2] https://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-SYNC-METHOD
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
333fc80a80