Re: fdatasync performance problem with large number of DB files
От | Fujii Masao |
---|---|
Тема | Re: fdatasync performance problem with large number of DB files |
Дата | |
Msg-id | 3d1086bd-0881-e0a3-9f4f-bda608f07fdb@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: fdatasync performance problem with large number of DB files (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: fdatasync performance problem with large number of DB files
|
Список | 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 по дате отправления: