Re: fdatasync performance problem with large number of DB files

On 2021/03/19 11:22, Fujii Masao wrote:
>
>
> On 2021/03/19 10:37, Thomas Munro wrote:
>> On Fri, Mar 19, 2021 at 2:16 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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.

0002 patch looks good to me. Thanks!
I have minor comments.

- * Issue fsync recursively on PGDATA and all its contents, or issue syncfs for
- * all potential filesystem, depending on recovery_init_sync_method setting.
+ * Issue fsync recursively on PGDATA and all its contents, issue syncfs for
+ * all potential filesystem, or do nothing, depending on
+ * recovery_init_sync_method setting.

The comment in SyncDataDirectory() should be updated so that
it mentions "none" method, as the above?

+ This is only safe if all buffered data is known to have been flushed
+ to disk already, for example by a tool such as
+ <application>pg_basebackup</application>. It is not a good idea to

Isn't it better to add something like "without <literal>--no-sync</literal>"
to "pg_basebackup" part? Which would prevent users from misunderstanding
that pg_basebackup always ensures that whatever options are specified.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION