Horton

Re: fdatasync performance problem with large number of DB files

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, 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-22T04:45:24Z
Lists: pgsql-hackers 
On Fri, Jun 18, 2021 at 06:18:59PM +0900, Fujii Masao wrote:
> 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.

Good point about restart_after_crash, I did not consider that.
Switching recovery_init_sync_method to SIGHUP could be helpful with
that.
--
Michael

Commits

  1. Change recovery_init_sync_method to PGC_SIGHUP.

  2. Provide recovery_init_sync_method=syncfs.