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

  1. Change recovery_init_sync_method to PGC_SIGHUP.

  2. Provide recovery_init_sync_method=syncfs.