Re: fd.c: flush data problems on osx

On 2016-04-13 17:21:01 -0400, Tom Lane wrote:
> I concluded that sharing the code would be more trouble than it's worth,
> because initdb.c's version of this is in fact not broken: it was never
> taught about mmap, and it doesn't need to be IMO, because it's not that
> performance-critical.

Agreed, there seems little immediate reason to go through additional
trouble. The issue of posix_fadvise(DONTNEED) dropping the cache seems
much less severe for initdb, than for the flushing patch (where it'd
obviously hurt).

It's probably good to unify the paths at some point in the future
though. We're lacking fsyncs in a bunch of relatively important paths
(WIP patch for most of them posted), and we end up needing fsync (and
probably the flushing logic) in the backend, initdb,
pg_basebackup/pg_recvlogical, pg_rewind and possibly some others that I
forgot about.

> I fixed the other things I complained about and pushed this.

Thanks for taking care of it!

> Please check to see that the committed patch resolves your original problem.

I looked through the commit, and I only have one very minor nitpick:
It might be good if
+ * We compile all alternatives that are supported on the current platform,
+ * to find portability problems more easily.
noted that we also fall through the approaches.

I'm not entirely sure what

+ /*
+ * Caution: do not call pg_flush_data with amount = 0, it could trash the
+ * file's seek position.
+ */
+ if (amount <= 0)
+ return;
+

is about?

- Andres