Re: fdatasync(2) on macOS

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> While following along with the nearby investigation into weird
> cross-version Apple toolchain issues that confuse configure, I noticed
> that the newer buildfarm Macs say:
> checking for fdatasync... (cached) yes
> That's a bit strange because there's no man page and no declaration:

Yeah, it's been there but undeclared for a long time. Who knows why.

> So... does this unreleased function flush drive caches? We know that
> fsync(2) doesn't, based on Apple's advice[1] for databases hackers to
> call fcntl(fd, F_FULLSYNC, 0) instead. We do that.

pg_test_fsync results make it clear that fdatasync is the same or a shade
faster than fsync, which is pretty much what you'd expect. On my
late-model Macbook Pro:

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 14251.416 ops/sec 70 usecs/op
fdatasync 25345.103 ops/sec 39 usecs/op
fsync 24677.445 ops/sec 41 usecs/op
fsync_writethrough 41.519 ops/sec 24085 usecs/op
open_sync 14188.903 ops/sec 70 usecs/op

and on an old Mac mini with spinning rust:

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 2536.535 ops/sec 394 usecs/op
fdatasync 4602.192 ops/sec 217 usecs/op
fsync 4600.365 ops/sec 217 usecs/op
fsync_writethrough 12.135 ops/sec 82404 usecs/op
open_sync 2506.674 ops/sec 399 usecs/op

So it's not a no-op, but on the other hand it's not succeeding in getting
bits down to the platter. I'm not inclined to dike it out, but it does
seem problematic that we're defaulting to open_datasync, which is also
not getting bits down to the platter.

I have a vague recollection that we discussed changing the default
wal_sync_method for Darwin years ago, but I don't recall why we
didn't pull the trigger. These results certainly suggest that
we oughta.

regards, tom lane