Re: should frontend tools use syncfs() ? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: should frontend tools use syncfs() ?
Date
Msg-id YVUz0Ay9KshniWBe@paquier.xyz
Whole thread Raw
In response to should frontend tools use syncfs() ?  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: should frontend tools use syncfs() ?  (Thomas Munro <thomas.munro@gmail.com>)
Re: should frontend tools use syncfs() ?  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Wed, Sep 29, 2021 at 07:43:41PM -0500, Justin Pryzby wrote:
> Forking this thread in which Thomas implemented syncfs for the startup process
> (61752afb2).
> https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BSG9jSW3ekwib0cSdC0yD-jReJ21X4bZAmqxoWTLTc2A%40mail.gmail.com
>
> Is there any reason that initdb/pg_basebackup/pg_checksums/pg_rewind shouldn't
> use syncfs()  ?

That makes sense.

> do_syncfs() is in src/backend/ so would need to be duplicated^Wimplemented in
> common.

The fd handling in the backend makes things tricky if trying to plug
in a common interface, so I'd rather do that as this is frontend-only
code.

> They can't use the GUC, so need to add an cmdline option or look at an
> environment variable.

fsync_pgdata() is going to manipulate many inodes anyway, because
that's a code path designed to do so.  If we know that syncfs() is
just going to be better, I'd rather just call it by default if
available and not add new switches to all the frontend tools in need
of flushing the data folder, switches that are not documented in your
patch.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From:
Date:
Subject: RE: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented
Next
From: Osumi, Takamichi/大墨 昂道
Date:
Subject: RE: Failed transaction statistics to measure the logical replication progress