Re: fdatasync performance problem with large number of DB files
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Paul Guo <guopa@vmware.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Brown <michael.brown@discourse.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-03-18T14:03:52Z
Lists: 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.
Commits
-
Change recovery_init_sync_method to PGC_SIGHUP.
- 34a8b64b4e5f 14.0 landed
-
Provide recovery_init_sync_method=syncfs.
- 61752afb2640 14.0 landed