Re: Two fsync related performance issues?

On Thu, Sep 3, 2020 at 11:30 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Wed, May 27, 2020 at 12:31 AM Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> > On Tue, 12 May 2020, 08:42 Paul Guo, <pguo(at)pivotal(dot)io> wrote:
> >> 1. StartupXLOG() does fsync on the whole data directory early in the crash recovery. I'm wondering if we could skip some directories (at least the pg_log/, table directories) since wal, etc could ensure consistency. Here is the related code.
> >>
> >> if (ControlFile->state != DB_SHUTDOWNED &&
> >> ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY)
> >> {
> >> RemoveTempXlogFiles();
> >> SyncDataDirectory();
> >> }

> 4. In datadir_fsync_fname(), if ParseRelationPath() is able to
> recognise a file as being a relation file, build a FileTag and call
> RegisterSyncRequest() to tell the checkpointer to sync this file as
> part of the end checkpoint (currently the end-of-recovery checkpoint,
> but that could also be relaxed).

For the record, Andres Freund mentioned a few problems with this
off-list and suggested we consider calling Linux syncfs() for each top
level directory that could potentially be on a different filesystem.
That seems like a nice idea to look into.