Re: fdatasync performance problem with large number of DB files - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: fdatasync performance problem with large number of DB files
Date
Msg-id CA+hUKGKgj+SN6z91nVmOmTv2KYrG7VnAGdTkWdSjbOPghdtooQ@mail.gmail.com
Whole thread Raw
In response to Re: fdatasync performance problem with large number of DB files  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses 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>)
List 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).

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Type of wait events WalReceiverWaitStart and WalSenderWaitForWAL
Next
From: Bharath Rupireddy
Date:
Subject: Re: Parallel Inserts in CREATE TABLE AS