Re: pgsql: Allow using syncfs() in frontend utilities.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Nathan Bossart <nathan(at)postgresql(dot)org>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Allow using syncfs() in frontend utilities.
Date: 2024-03-22 16:52:15
Message-ID: CA+TgmobUiqKr+ZMCLc5Qap-sXBnjfGUU+ZBmzYEjUuWyjsGr1g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, Sep 6, 2023 at 7:28 PM Nathan Bossart <nathan(at)postgresql(dot)org> wrote:
> Allow using syncfs() in frontend utilities.
>
> This commit allows specifying a --sync-method in several frontend
> utilities that must synchronize many files to disk (initdb,
> pg_basebackup, pg_checksums, pg_dump, pg_rewind, and pg_upgrade).
> On Linux, users can specify "syncfs" to synchronize the relevant
> file systems instead of calling fsync() for every single file. In
> many cases, using syncfs() is much faster.
>
> As with recovery_init_sync_method, this new option comes with some
> caveats. The descriptions of these caveats have been moved to a
> new appendix section in the documentation.

Hi,

I'd like to complain about this commit's addition of a new appendix. I
do understand the temptation to document caveats like this centrally
instead of in multiple places, but as I've been complaining about over
in the "documentation structure" thread, our top-level documentation
index is too big, and I feel strongly that we need to de-clutter it
rather than cluttering it further. This added a new chapter which is
just 5 sentences long. I understand that this was done because the
same issue applies to a bunch of different utilities and we didn't
want to duplicate this text in all of those places, but I feel like
this approach just doesn't scale. If we did this in every place where
we have this much text that we want to avoid duplicating, we'd soon
have hundreds of appendixes.

What I would suggest we do instead is pick one of the places where
this comes up and document it there, perhaps the
recovery_init_sync_method GUC. And then make the documentation for the
other say something like, you know those issues we documented for
recovery_init_sync_method? Well they also apply to this.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Daniel Gustafsson 2024-03-22 20:30:20 pgsql: Add notBefore and notAfter to SSL cert info display
Previous Message Alexander Korotkov 2024-03-22 13:26:03 pgsql: Fix an oversight in refactoring in 06b10f80ba4.

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-03-22 16:53:05 Re: Cannot find a working 64-bit integer type on Illumos
Previous Message Japin Li 2024-03-22 16:48:05 Cannot find a working 64-bit integer type on Illumos