Horton

Re: should frontend tools use syncfs() ?

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Thomas Munro <thomas.munro@gmail.com>, David Steele <david@pgmasters.net>, Fujii Masao <masao.fujii@oss.nttdata.com>, Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Brown <michael.brown@discourse.org>, pgsql-hackers@postgresql.org
Date: 2023-09-01T02:17:27Z
Lists: pgsql-hackers

Attachments

On Fri, Sep 01, 2023 at 10:40:12AM +0900, Michael Paquier wrote:
> That should be OK this way.  The extra running time is not really
> visible, right?

AFAICT it is negligible.  Presumably it could take a little longer if there
is a lot to sync on the file system, but I don't know if that's worth
worrying about.

> +command_ok([ 'initdb', '-S', $datadir, '--sync-method', 'fsync' ],
> +   'sync method fsync');
> 
> Removing this one may be fine, actually, because we test the sync
> paths on other places like pg_dump.

Done.

> This split is OK by me, so WFM.

Cool.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Commits

  1. Adjust documentation for syncfs().

  2. Improve the naming in wal_sync_method code.

  3. Allow using syncfs() in frontend utilities.

  4. Add support for syncfs() in frontend support functions.

  5. Make enum for sync methods available to frontend code.

  6. Move PG_TEMP_FILE* macros to file_utils.h.

  7. Change client-side fsync_fname() to report errors fatally