Re: fdatasync performance problem with large number of DB files - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: fdatasync performance problem with large number of DB files
Date
Msg-id 2589e842-41be-5d83-4616-216acf0a59da@oss.nttdata.com
Whole thread Raw
In response to Re: fdatasync performance problem with large number of DB files  (Thomas Munro <thomas.munro@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: locking [user] catalog tables vs 2pc vs logical rep
Next
From: Ashutosh Bapat
Date:
Subject: Re: disfavoring unparameterized nested loops