Re: fdatasync performance problem with large number of DB files

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: fdatasync performance problem with large number of DB files
Дата
Msg-id CA+hUKGKgj+SN6z91nVmOmTv2KYrG7VnAGdTkWdSjbOPghdtooQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: fdatasync performance problem with large number of DB files  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: fdatasync performance problem with large number of DB files  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Re: fdatasync performance problem with large number of DB files  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
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.

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).

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.  Let's see if anyone else would
like to vote for or against the concept of the 0002 patch
(recovery_init_sync_method=none).

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Type of wait events WalReceiverWaitStart and WalSenderWaitForWAL
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Parallel Inserts in CREATE TABLE AS