Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
Marco Boeringa <marco@boeringa.demon.nl>
From: Marco Boeringa <marco@boeringa.demon.nl>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2025-10-06T16:17:11Z
Lists: pgsql-bugs
Hi Andras, I am not really a Linux / Ubuntu expert. Can you give me a suggestion for how to create such a CPU profile for the specific PostgreSQL processes getting stuck? Marco Op 6-10-2025 om 18:13 schreef Andres Freund: > Hi, > > On 2025-10-06 18:09:25 +0200, Marco Boeringa wrote: >> I should have phrased it better. The high processor and core activity is not >> unexpected. The code is designed to saturate the processor and maximize >> throughput by careful design of the Python threading stuff. It is just that >> all the jobs send to PostgreSQL via ODBC for the specific step in the >> processing and with the small Italy extract, should return in less than 10 >> seconds (which they do in those lucky runs I do not observe the issue), but >> some of the jobs for the specific step don't, e.g. 30 jobs return within 10 >> seconds, then the remaining 14 unexpectedly get stuck for 2 hours before >> returning, all the while staying at the same high core usage they were >> initiated with. >> So some of the PostgreSQL database sessions, as I already explained show up >> in pgAdmin as 'active' with no wait events or blocking pids, simply take an >> excessive amount of time, but will ultimately return. > We need a profile of those processes while they use excessive amount of > time. If they don't have wait events they're using CPU time, and seeing a > profile of where all that time is spent might provide enough information where > to look in more detail. > > Greetings, > > Andres Freund