Horton

Re: fdatasync performance problem with large number of DB files

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread View on postgr.es
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Justin Pryzby <pryzby@telsasoft.com>, Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>, David Steele <david@pgmasters.net>, Bruce Momjian <bruce@momjian.us>, Paul Guo <guopa@vmware.com>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Brown <michael.brown@discourse.org>, pgsql-hackers@postgresql.org
Date: 2021-06-18T09:18:59Z
Lists: pgsql-hackers 

On 2021/06/04 23:39, Justin Pryzby wrote:
> You said switching to SIGHUP "would have zero effect"; but, actually it allows
> an admin who's DB took a long time in recovery/startup to change the parameter
> without shutting down the service.  This mitigates the downtime if it crashes
> again.  I think that's at least 50% of how this feature might end up being
> used.

Yes, it would have an effect when the server is automatically restarted
after crash when restart_after_crash is enabled. At least for me +1 to
your proposed change.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Commits

  1. Change recovery_init_sync_method to PGC_SIGHUP.

  2. Provide recovery_init_sync_method=syncfs.