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 3d1086bd-0881-e0a3-9f4f-bda608f07fdb@oss.nttdata.com
Whole thread Raw
In response to Re: fdatasync performance problem with large number of DB files  (Bruce Momjian <bruce@momjian.us>)
Responses Re: fdatasync performance problem with large number of DB files
List 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



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Disable WAL logging to speed up data loading
Next
From: Bruce Momjian
Date:
Subject: Re: Key management with tests