On Mon, Jul 18, 2022 at 3:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> 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.