Re: Windows now has fdatasync()

On Fri, Apr 8, 2022 at 7:56 PM Dave Page <dpage@pgadmin.org> wrote:
> Windows 8 was a pretty unpopular release, so I would expect shifting to 10/2016+ for PG 16 would be unlikely to be a major problem.

Thanks to Michael for making that happen.  That removes the main thing
I didn't know how to deal with in this patch.  Here's a rebase with
some cleanup.

With my garbage collector hat on, I see that all systems we target
have fdatasync(), except:

1.  Windows, but this patch supplies src/port/fdatasync.c.
2.  DragonflyBSD before 6.1.  We have 6.0 in the build farm.
3.  Ancient macOS.  Current releases have it, though we have to cope
with a missing declaration.

From a standards point of view, fdatasync() is issue 5 POSIX like
fsync().  Both are optional, but, being a database, we require
fsync(), and they're both covered by the same POSIX option
"Synchronized Input and Output".

My plan now is to commit this patch so that problem #1 is solved, prod
conchuela's owner to upgrade to solve #2, and wait until Tom shuts
down prairiedog to solve #3.  Then we could consider removing the
HAVE_FDATASYNC probe and associated #ifdefs when convenient.  For that
reason, I'm not too bothered about the slight weirdness of defining
HAVE_FDATASYNC on Windows even though that doesn't come from
configure; it'd hopefully be short-lived.  Better ideas welcome,
though.  Does that make sense?