Josh Berkus <j...@agliodbs.com> writes:
>>> I am unclear as to the reason why there is a test for
>>> HAVE_FSYNC_WRITETHROUGH_ONLY in pg_fsync().  Perhaps that is also
>>> leftover from a previous vision of how this all works?  Or does an
>>> fsync() call actually fail on Windows?

>> No, fsync responds fine.  It just don't actually sync to disk.

Sigh ... The closer I look at the Windows code path here, the more of an
inconsistent, badly documented spaghetti-heap it appears to be.  So far
as a quick Google search unearths, there is no fsync() primitive on
Windows.  What we have actually got is this gem in port/win32.h:

/*
 *      Even though we don't support 'fsync' as a wal_sync_method,
 *      we do fsync() a few other places where _commit() is just fine.
 */
#define fsync(fd) _commit(fd)

So actually, there is no difference between selecting fsync and
fsync_writethrough on Windows, this comment and the SGML documentation
to the contrary.  Both settings result in invoking _commit() and
presumably are safe.  One wonders why we bothered to invent a separate
fsync_writethrough setting on Windows.

What this means is that switching to a simple preference order
"fdatasync, then fsync" will result in choosing fsync on Windows (since
it hasn't got fdatasync), meaning _commit, meaning Windows users see
a behavioral change after all.

I'm afraid that if we don't want a major behavioral change, there's
no option except having a Windows-specific rule for the choice of
default.  It'll have to be "fdatasync, then fsync, except on Windows
where open_datasync is the default".  Grumble.  But it's not like
Windows hasn't got a hundred other special cases already.

Would someone verify via pgbench or similar test (*not* test_fsync) that
on Windows, wal_sync_method = fsync or fsync_writethrough perform the
same (ie tps ~= disk rotation rate) while open_datasync is too fast to
be real?  I'm losing confidence that I've found all the spaghetti ends
here, and I don't have a Windows setup to try it myself.

                        regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to