Message-ID: <934fc185-9583-4f03-902e-fa9f221fbea4@boeringa.demon.nl>
Date: Mon, 6 Oct 2025 12:40:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: Markus KARG <markus@headcrashing.eu>
Cc: pgsql-bugs@lists.postgresql.org
From: Marco Boeringa <marco@boeringa.demon.nl>
Subject: Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/934fc185-9583-4f03-902e-fa9f221fbea4%40boeringa.demon.nl>
Precedence: bulk

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