Hi Markus,
On my Ubuntu virtual machine, io_uring cannot be started. Setting
"io_method = io_uring" and trying to restart the cluster, fails. It will
not start, I have attempted this multiple times. Only 'sync' and
'worker' allow restarting after modifying the PostgreSQL configuration
file.
As I understood, the PostgreSQL binary needs to be compiled with the
proper support, maybe my version on Ubuntu 24.04 that runs as a Windows
Hyper-V virtual machine, doesn't have it. Although I did notice when
installing PG18 from synaptic, that it installed an additional
'liburing' package or something named like that if I remember well...
As to your question about Python and scheduling conflict: this is not
the case. Python runs on the Windows host, not under Ubuntu inside the
VM. I only have PostgreSQL installed on Ubuntu, as I use it with
osm2pgsql there. I access the PostgreSQL instance via pyodbc or psycopg2
on the Windows host, so it is like a remote database server, just
running on local hardware.
Marco
> I am not a PostgreSQL contributor and have no clue what the actual
> technical details are in the new AIO code, but reading your report the
> following questions came to my mind:
>
> * Does the failure also happen with io_mode=io_uring? If no, it is a
proof that it is really bound to io_mode=worker, not to AIO in general.
> * Does the failure also happen with io_mode=worker when your Python code
> uses only 22 cores, and PostgreSQL uses only 22 workers (so Python and
> PostgreSQL do not share CPU cores)? If no, it might indicate that the
> problem could be solved by increasing the execution policy in favor of
> PostgreSQL to give a hint to the scheduler that a CPU core should be
> given to PostgreSQL FIRST as Python most likely is waiting on it to
> continue, but PostgreSQL could not continue because the schedule gave
> all the cores to Python... (classical deadlock; eventually resolves once
> enough CPU cores are free to eventually finish the starving thread).
> HTH
> -Markus
