Re: aio: Async fsyncs for crash recovery and checkpointer

From: Yuhang Qiu <iamqyh(at)gmail(dot)com>
To: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Cc: Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: aio: Async fsyncs for crash recovery and checkpointer
Date: 2026-09-22 04:03:17
Message-ID: C24C12AB-DE89-4EC8-AF08-6157CDA9A8CA@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Nazir,

Thanks for the comparison. The main benefit of this patch series seems
to be in checkpointing rather than crash recovery, so I think further
testing should focus on that.

> For now, ordinary reopen failures for both relation and SLRU fsyncs
> return -errno.
>
> Done. Relation fsync requests now use io_max_concurrency as their
> limit.

These two changes LGTM.

> However, I think increasing the number of worker processes
> should solve this problem.

Increasing the worker count may help with worker availability, but it
doesn't address contention for storage bandwidth.

One more point: when a worker calls pg_fsync() or pg_fdatasync(), it checks
its own enableFsync. If the issuer has reloaded fsync=on but the worker
still has the old off value, the worker can skip the sync and report
success. Should the issuer's setting or the worker's determine whether
the sync is performed?

Best regards,
Yuhang Qiu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ZizhuanLiu X-MAN 2026-09-22 04:07:49 Re: Optimize MCV stats for sortable types and utilize sorted-order properties
Previous Message Manu 2026-09-22 03:54:17 Re: Temp schema drop leaves an inconsistent state behind