Re: fdatasync performance problem with large number of DB files
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Brown <michael.brown@discourse.org>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-03-16T08:10:28Z
Lists: pgsql-hackers
On 2021/03/15 8:33, Thomas Munro wrote: > On Mon, Mar 15, 2021 at 11:52 AM Thomas Munro <thomas.munro@gmail.com> wrote: >> Time being of the essence, here is the patch I posted last year, this >> time with a GUC and some docs. You can set sync_after_crash to >> "fsync" (default) or "syncfs" if you have it. > > Cfbot told me to add HAVE_SYNCFS to Solution.pm, and I fixed a couple of typos. Thanks for the patch! + When set to <literal>fsync</literal>, which is the default, + <productname>PostgreSQL</productname> will recursively open and fsync + all files in the data directory before crash recovery begins. Isn't this a bit misleading? This may cause users to misunderstand that such fsync can happen only in the case of crash recovery. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Commits
-
Change recovery_init_sync_method to PGC_SIGHUP.
- 34a8b64b4e5f 14.0 landed
-
Provide recovery_init_sync_method=syncfs.
- 61752afb2640 14.0 landed