Re: fdatasync performance problem with large number of DB files
От | Fujii Masao |
---|---|
Тема | Re: fdatasync performance problem with large number of DB files |
Дата | |
Msg-id | ca3983c4-0fb3-a64f-c533-ddba3e36b177@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: fdatasync performance problem with large number of DB files (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: fdatasync performance problem with large number of DB files
|
Список | pgsql-hackers |
On 2021/03/19 10:37, Thomas Munro wrote: > On Fri, Mar 19, 2021 at 2:16 PM Thomas Munro <thomas.munro@gmail.com> wrote: >> PS: For illustration/discussion, I've also attached a "none" patch. I >> also couldn't resist rebasing my "wal" mode patch, which I plan to >> propose for PG15 because there is not enough time left for this >> release. > > Erm... I attached the wrong version by mistake. Here's a better one. 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, ereport(LOG, (errcode_for_file_access(), errmsg("could not open \"%s\": %m", path))) Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: