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: Bruce Momjian <bruce@momjian.us>, Thomas Munro <thomas.munro@gmail.com>
Cc: Paul Guo <guopa@vmware.com>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Brown <michael.brown@discourse.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-03-18T16:50:22Z
Lists: pgsql-hackers 

On 2021/03/18 23:03, Bruce Momjian wrote:
>> Are we sure we want to use the word "crash" here?  I don't remember
>> seeing it used anywhere else in our user interface.

We have GUC restart_after_crash.


>  I guess it is
>> "crash recovery".
> 
> Maybe call it "recovery_sync_method"
+1. This name sounds good to me. Or recovery_init_sync_method, because that
sync happens in the initial phase of recovery.

Another idea from different angle is data_directory_sync_method. If we adopt
this, we can easily extend this feature for other use cases (other than sync at
the beginning of recovery) without changing the name.
I'm not sure if such cases actually exist, though.

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.