From: Marco Boeringa <marco@boeringa.demon.nl>
To: Markus KARG <markus@headcrashing.eu>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
Date: Mon, 6 Oct 2025 12:40:01 +0200
Message-ID: <934fc185-9583-4f03-902e-fa9f221fbea4@boeringa.demon.nl> (raw)
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: marco@boeringa.demon.nl, markus@headcrashing.eu, pgsql-bugs@lists.postgresql.org
Subject: Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
In-Reply-To: <934fc185-9583-4f03-902e-fa9f221fbea4@boeringa.demon.nl>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox