Re: Windows now has fdatasync()

On Mon, Jul 18, 2022 at 3:43 PM Tom Lane  wrote:
> Thomas Munro  writes:
> > 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.
>
> Hmmm ... according to [1], while current macOS has an undocumented
> fdatasync function, it doesn't seem to do anything as useful as,
> say, sync data to disk.  I'm not sure what direction you're headed
> in here, but it probably shouldn't include assuming that fdatasync
> is actually useful on macOS.  But maybe that's not your point?

Oh, I'm not planning to change the default choice on macOS (or
Windows).  I *am* assuming we're not going to take it away as an
option, that cat being out of the bag ever since configure found
Apple's secret fdatasync (note that O_DSYNC, our default, is also
undocumented and also known not to flush caches, but at least it's
present in an Apple header!).  I was just noting an upcoming
opportunity to remove the configure/meson probes for fdatasync, which
made me feel better about the slightly kludgy way this patch is
defining HAVE_FDATASYNC explicitly on Windows.

> > 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.
>
> You could force my hand by pushing something that requires this ;-).

Heh.  Let me ask about the DragonFlyBSD thing first.