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  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: Disable WAL logging to speed up data loading
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Key management with tests