Re: fdatasync performance problem with large number of DB files
От | Bruce Momjian |
---|---|
Тема | Re: fdatasync performance problem with large number of DB files |
Дата | |
Msg-id | 20210318140352.GC8529@momjian.us обсуждение исходный текст |
Ответ на | 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 Thu, Mar 18, 2021 at 09:54:11AM -0400, Bruce Momjian wrote: > On Thu, Mar 18, 2021 at 11:19:13PM +1300, Thomas Munro wrote: > > On Thu, Mar 18, 2021 at 8:52 PM Paul Guo <guopa@vmware.com> wrote: > > > About the syncfs patch, my first impression on the guc name sync_after_crash > > > is that it is a boolean type. Not sure about other people's feeling. Do you guys think > > > It is better to rename it to a clearer name like sync_method_after_crash or others? > > > > Works for me. Here is a new version like that, also including the > > documentation change discussed with Fujii-san, and a couple of > > cosmetic changes. > > Are we sure we want to use the word "crash" here? I don't remember > seeing it used anywhere else in our user interface. I guess it is > "crash recovery". Maybe call it "recovery_sync_method"? -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
В списке pgsql-hackers по дате отправления: