Re: BUG #19792: BUG: Deadlock between WaitIO and read-stream look-ahead under io_method=io_uring (18.6)

Hi Shihao,

Thanks for looking into this and for the patch, looks promising! I'm happy
to test it, however it might be complicated to verify this.

We've been running workload on io_uring for 4 months without any issue. So
far the issue appeared on 2 independent clusters,
with a fairly heavy I/O workload (lots of autovacuum). After restarting the
postgresql process (and db recovery) the cluster continued
to run workload for months (with the same io_method = io_uring) without
hitting this bug.

Regards,
Tomas

On Sun, 25 Oct 2026 at 19:31, shihao zhong <zhong950419(at)gmail(dot)com> wrote:

> Hi Thomas,
>
> Thanks for the report.
>
> I'm starting to learn AIO and have no Linux machine for io_uring, so I
> could not
> reproduce this with a real workload. From the code, I think it goes
> like this.
>
> t1 A: an INSERT splitting leaf 627 holds its lock.
> t2 B: autovacuum's btree scan starts a look-ahead read of 628.
> BM_IO_IN_PROGRESS is set, but io_wref is not yet.
> t3 A: gets 628 from the FSM. WaitIO() sees no io_wref, so it
> sleeps on the buffer CV.
> t4 B: stages the IO and sets io_wref, but does not wake A.
> t5 B: waits for the lock on 627 that A holds.
> t6 A and B wait on each other forever.
>
> With io_uring, only the owner or a backend that waits through io_wref
> reaps the completion, so nobody reaps it. [1] only fixes waits
> through io_wref, and A never gets there.
>
> 0001 is Thomas Munro's patch from [1]. A woken A can find the IO
> still staged, and waits on submit_cv.
> 0002 wakes the buffer CV once io_wref is set. It also wakes
> submit_cv after synchronous execution, which 0001 misses.
>
> Draft attached. Could someone check them?
>
> [1]
> https://www.postgresql.org/message-id/CA%2BhUKG%2BmZYrSdnhk-XrBYO18H829K77S9gMKUsykOiTJtqB43g%40mail.gmail.com
>
> Thanks,
> Shihao
>