Re: Final(?) proposal for wal_sync_method changes

Josh Berkus <josh@agliodbs.com> writes:
> I agree for the backpatch that we should just swap to fdatasync as 
> default, and should not attempt to add the extra options.

I noticed while updating the documentation for this that the current
documentation is a flat-out lie.  It claims that the preference order
for wal_sync_method is       open_datasync       fdatasync       fsync_writethrough       fsync       open_sync
ie you get the first-listed method that is supported on a given
platform.  But this is not so: actually, fsync_writethrough will
be selected as default ONLY on Windows.  There are other platforms
where the option exists, OS X being the one I have at hand.  The
misstatement is masked on OS X because it also has open_datasync
and fdatasync.  But since we are about to delete open_datasync from
the list, it's possible there are platforms where it will be exposed.

Oh, and just to add insult to injury, the above is what config.sgml
says, but postgresql.conf.sample says something different.

So I'm wondering whether we should correct the code to match the docs,
or vice versa.  The former would just be a matter of saying#elif defined(HAVE_FSYNC_WRITETHROUGH)#define
DEFAULT_SYNC_METHOD       SYNC_METHOD_FSYNC_WRITETHROUGH
 
in place of#elif defined(HAVE_FSYNC_WRITETHROUGH_ONLY)#define DEFAULT_SYNC_METHOD
SYNC_METHOD_FSYNC_WRITETHROUGH
To do the latter we'd have to say something like "The default is
fdatasync if it exists, else fsync, except on Windows where it is
fsync_writethrough".

Changing the code would result in a sudden, massive performance change
if there are any platforms for which fsync_writethrough exists but not
fdatasync.  But I'm not sure if there are any.

Another point here is that it's not clear why we're selecting a
known-to-be-insecure default on OS X (where in fact all methods except
fsync_writethrough fail to push data to disk).  We've been around on
that before, of course, and maybe now is not the time to change it.

Thoughts?
        regards, tom lane