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>
Cc: Bruce Momjian <bruce@momjian.us>, Paul Guo <guopa@vmware.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Michael Brown <michael.brown@discourse.org>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-03-19T07:34:57Z
Lists: pgsql-hackers
On 2021/03/19 14:28, Thomas Munro wrote: > On Fri, Mar 19, 2021 at 3:23 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote: >> Thanks for updating the patch! It looks good to me! >> I have one minor comment for the patch. >> >> + elog(LOG, "could not open %s: %m", path); >> + return; >> + } >> + if (syncfs(fd) < 0) >> + elog(LOG, "could not sync filesystem for \"%s\": %m", path); >> >> Since these are neither internal errors nor low-level debug messages, ereport() should be used for them rather than elog()? For example, > > Fixed. Thanks! LGTM. > I'll let this sit until tomorrow to collect any other feedback or > objections, and then push the 0001 patch > (recovery_init_sync_method=syncfs). Understood. > On Fri, Mar 19, 2021 at 4:08 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote: >> 0002 patch looks good to me. Thanks! >> I have minor comments. > > Ok, I made the changes you suggested. Thanks! LGTM. > Let's see if anyone else would > like to vote for or against the concept of the 0002 patch > (recovery_init_sync_method=none). Agreed. I also want to hear more opinion about the setting "none". 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