aio: Don't silently drop wait_event_info
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253487psql -h localhost -U postgresBuilt from patchset v3 (message #3), August 23, 2026 at 11:11 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253487_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253487_3 && git checkout t253487_3Patchset v3 (message #3) is on t253487_3
Hi,
While working on something else in the AIO code I noticed that
FileStartReadV() accepts a wait_event_info argument but never passes
it. Instead pgaio_io_perform_synchronously() hardcodes the wait event
to WAIT_EVENT_DATA_FILE_READ, so a wait event supplied by the caller
is silently ignored.
This is not a live bug today. The only caller of FileStartReadV() is
md.c, and it passes exactly the WAIT_EVENT_DATA_FILE_READ that is
hardcoded anyway; pgaio_io_start_writev() has no callers at all yet.
Fix this by storing the wait event in PgAioOpData and reporting it.
--
Regards,
Nazir Bilal Yavuz
Microsoft
Hi,
On 2026-08-19 13:31:28 +0300, Nazir Bilal Yavuz wrote:
While working on something else in the AIO code I noticed that
FileStartReadV() accepts a wait_event_info argument but never passes
it. Instead pgaio_io_perform_synchronously() hardcodes the wait event
to WAIT_EVENT_DATA_FILE_READ, so a wait event supplied by the caller
is silently ignored.This is not a live bug today. The only caller of FileStartReadV() is
md.c, and it passes exactly the WAIT_EVENT_DATA_FILE_READ that is
hardcoded anyway; pgaio_io_start_writev() has no callers at all yet.
Yep, that should be fixed.
Fix this by storing the wait event in PgAioOpData and reporting it.
I don't think that's quite the right fix though - PgAioOpData is for data that
differs between operations, but it seems this is something that's relevant
across all of the eventually supported operations. So I think it should be
implemented in a more generic place?
Greetings,
Andres Freund
Hi,
Thanks for looking into this!
On Wed, 19 Aug 2026 at 16:27, Andres Freund <andres@anarazel.de> wrote:
On 2026-08-19 13:31:28 +0300, Nazir Bilal Yavuz wrote:
Fix this by storing the wait event in PgAioOpData and reporting it.
I don't think that's quite the right fix though - PgAioOpData is for data that
differs between operations, but it seems this is something that's relevant
across all of the eventually supported operations. So I think it should be
implemented in a more generic place?
One general place is PgAioHandle, I put wait_event_info into
PgAioHandle but now its size is increased from 144 to 152. I couldn't
find a better place, do you have any suggestions?
--
Regards,
Nazir Bilal Yavuz
Microsoft
At 2026-08-20 18:56:32, "Nazir Bilal Yavuz" <byavuz81@gmail.com> wrote:
One general place is PgAioHandle, I put wait_event_info into
PgAioHandle but now its size is increased from 144 to 152. I couldn't
find a better place, do you have any suggestions?
Hi,
I've reviewed your patch.
I noticed that under the default io_method=worker,
asynchronous reads from mdreadv still report AIO_IO_COMPLETION when the backend gets blocked.
The caller‑supplied wait_event_info is still being ignored.
Is this a problem?
Best regards,
--
Yilin Zhang
Hi,
Thank you for looking into this!
On Thu, 20 Aug 2026 at 14:32, Yilin Zhang <jiezhilove@126.com> wrote:
At 2026-08-20 18:56:32, "Nazir Bilal Yavuz" <byavuz81@gmail.com> wrote:
One general place is PgAioHandle, I put wait_event_info into
PgAioHandle but now its size is increased from 144 to 152. I couldn't
find a better place, do you have any suggestions?Hi,
I've reviewed your patch.
I noticed that under the default io_method=worker,
asynchronous reads from mdreadv still report AIO_IO_COMPLETION when the backend gets blocked.
The caller‑supplied wait_event_info is still being ignored.
Is this a problem?
I don't think it is a problem, these are two separate wait events,
reported by two different processes at the same time.
- AIO_IO_COMPLETION is reported when one backend (client backend for
example) is waiting IO to be done by someone else.
- wait_event_info (WAIT_EVENT_DATA_FILE_READ in this case) is used
when the actual backend doing the IO is waiting IO to be completed.
--
Regards,
Nazir Bilal Yavuz
Microsoft