Horton

Re: should frontend tools use syncfs() ?

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
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-08-30T00:10:47Z
Lists: pgsql-hackers 
On Tue, Aug 29, 2023 at 08:45:59AM -0700, Nathan Bossart wrote:
> rebased

0001 looks OK, worth its own, independent, commit.

I understand that I'm perhaps sounding pedantic about fsync_pgdata()..
But, after thinking more about it, I would still make this code fail
hard with an exit(EXIT_FAILURE) to let any C code calling directly
this routine with sync_method = DATA_DIR_SYNC_METHOD_SYNCFS know that
the build does not allow the use of this option when we don't have
HAVE_SYNCFS.  parse_sync_method() offers some protection, but adding
this restriction also in the execution path is more friendly than
falling back silently to the default of flushing each file if
fsync_pgdata() is called with syncfs but the build does not support
it.  At least that's more predictible.

I'm fine with the doc changes.
--
Michael

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