Re: Windows now has fdatasync()

On Fri, Apr 8, 2022 at 7:56 PM Dave Page <dpage(at)pgadmin(dot)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?