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