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-08-30T01:14:08Z
Lists: pgsql-hackers

Attachments

On Wed, Aug 30, 2023 at 09:10:47AM +0900, Michael Paquier wrote:
> 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.

That seems fair enough.  I did this in v7.  I restructured fsync_pgdata()
and fsync_dir_recurse() so that any new sync methods should cause compiler
warnings until they are implemented.

-- 
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