[Bug] Possible io_uring FD leak across crash recovery

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