The following bug has been logged on the website:
Bug reference: 19725
Logged by: weijie JL
Email address: weijie1006jl@gmail.com
PostgreSQL version: 18.6
Operating system: RockyLinux9
Description:
Hello,
I can reproduce a read failure during pg_restore with io_method=io_uring.
The error disappears with worker and recurs after switching back to
io_uring.
Environment:
- PostgreSQL 18.6, x86_64
- VMware VM: 8 vCPUs, 32 GB RAM
- Kernel: 5.14.0-611.55.1.el9_7.x86_64
Settings:
effective_io_concurrency = 256
maintenance_io_concurrency = 16
max_parallel_maintenance_workers = 2
Restore command:
nohup pg_restore -d test001 dhr.dump/ -j8 -v > test.log 2>&1 &
One failing statement:
ALTER TABLE ONLY dhr.obj_permission_object
ADD CONSTRAINT obj_permission_object_pkey PRIMARY KEY (id);
Server error:
ERROR: could not read blocks 143..158 in file "base/1684908/1686127":
Operation canceled
LOCATION: md_readv_report, md.c:2059
SQLSTATE: XX000
Observed test sequence:
1. io_method=io_uring: the read error occurred during index creation.
2. Changed io_method to worker: retried without errors.
3. Changed io_method back to io_uring: the read error was reproduced.
I have not measured the failure rate or prepared a self-contained
minimal reproducer.
One earlier run also reported "could not map dynamic shared memory
segment" from parallel workers immediately after the read error.
Those DSM errors have not recurred in subsequent failing tests.
Does this match a known PostgreSQL bug or kernel-side io_uring issue?
What additional logs or tracing would help identify the cause?
Thank you.
