Re: fdatasync performance problem with large number of DB files

On Thu, Mar 11, 2021 at 1:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Thinking about this some more, if you were to propose a patch like
> > that syncfs() one but make it a configurable option, I'd personally be
> > in favour of trying to squeeze it into v14.  Others might object on
> > commitfest procedural grounds, I dunno, but I think this is a real
> > operational issue and that's a fairly simple and localised change.
> > I've run into a couple of users who have just commented that recursive
> > fsync() code out!
>
> I'm a little skeptical about the "simple" part.  At minimum, you'd
> have to syncfs() each tablespace, since we have no easy way to tell
> which of them are on different filesystems.  (Although, if we're
> presuming this is Linux-only, we might be able to tell with some
> unportable check or other.)

Right, the patch knows about that:

+    /*
+     * On Linux, we don't have to open every single file one by one.  We can
+     * use syncfs() to sync whole filesystems.  We only expect filesystem
+     * boundaries to exist where we tolerate symlinks, namely pg_wal and the
+     * tablespaces, so we call syncfs() for each of those directories.
+     */