Horton

Re: should frontend tools use syncfs() ?

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Nathan Bossart <nathandbossart@gmail.com>, 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-08-21T20:08:46Z
Lists: pgsql-hackers 
On Wed, Aug 16, 2023 at 11:50 PM Michael Paquier <michael@paquier.xyz> wrote:
> >> Do we actually need --no-sync at all if --sync-method is around?  We
> >> could have an extra --sync-method=none at option level with --no-sync
> >> still around mainly for compatibility?  Or perhaps that's just
> >> over-designing things?
> >
> > I don't have a strong opinion.  We could take up deprecating --no-sync in a
> > follow-up thread, though.  Like you said, we'll probably need to keep it
> > around for backward compatibility, so it might not be worth the trouble.
>
> Okay, maybe that's not worth it.

Doesn't seem worth it to me. I think --no-sync is more intuitive than
--sync-method=none, it's certainly shorter, and it's a pretty
important setting because we use it when running the regression tests.

-- 
Robert Haas
EDB: http://www.enterprisedb.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