Re: fdatasync performance problem with large number of DB files

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: fdatasync performance problem with large number of DB files
Дата
Msg-id 10b5b192-21e9-bf28-b22e-ab8ebb9e77d1@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: fdatasync performance problem with large number of DB files  (Thomas Munro <thomas.munro@gmail.com>)
Список 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



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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Parallel Inserts in CREATE TABLE AS
Следующее
От: "iwata.aya@fujitsu.com"
Дата:
Сообщение: RE: libpq debug log