Hi, I think I ran into an io_uring FD leak while chasing the CFBot failures for the no-core PANIC patch [1]. Both Linux Meson jobs in [2] use io_method=io_uring and hit this after several deliberate crashes:
FATAL: could not setup io_uring queue: Too many open files HINT: Consider increasing "ulimit -n" to at least 1132. To rule out the test hook, I also tried killing an ordinary backend with SIGKILL and waiting for recovery each time. With io_method=io_uring and ulimit -n 1024, I saw the following ring FD counts in the postmaster. Its PID stayed the same throughout: initial: 142 recovery 1: 284 recovery 2: 426 recovery 3: 568 recovery 4: 710 recovery 5: 852 recovery 6: 994 recovery 7: failed with EMFILE AFAICS, pgaio_uring_shmem_init() creates a fresh set of rings each time the postmaster reinitializes shmem. I couldn't find a matching io_uring_queue_exit() for the old set. The postmaster is still alive, so those FDs would stick around. FWIW, I tried adding an on_shmem_exit callback to call io_uring_queue_exit() for the initialized rings. With that change, the postmaster's io_uring FD count stayed at 142 through ten crash/recovery cycles. Am I missing an existing cleanup path here? [1] https://www.postgresql.org/message-id/CAJTYsWV601xS0D_SrZ111VX0N%2BtRe2fjK-VjY75v1gNJ93%2BjkQ%40mail.gmail.com [2] https://github.com/postgres/postgres-cfbot/actions/runs/34815719686 Regards, Ayush
