Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
От | Marco Boeringa |
---|---|
Тема | Re: Potential "AIO / io workers" inter-worker locking issue in PG18? |
Дата | |
Msg-id | 934fc185-9583-4f03-902e-fa9f221fbea4@boeringa.demon.nl обсуждение исходный текст |
Ответ на | Potential "AIO / io workers" inter-worker locking issue in PG18? (Marco Boeringa <marco@boeringa.demon.nl>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: