Thread

Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring

Jakub Wartak <jakub.wartak@enterprisedb.com> — 2025-11-10T08:59:58Z

On Fri, Nov 7, 2025 at 11:50 PM Tomas Vondra <tomas@vondra.me> wrote:
> On 9/22/25 10:45, Jakub Wartak wrote:
>
> The v2 patch got no response for 1+ month, it seems. I see it adds info
> to two places - sgml docs and elog().
>
> I'm skeptical about the elog() changes. Maybe the log level change would
> be good? But as Andres pointed out the people seeing this may not have a
> chance to address the issue.

Hi Tomas,

You both expressed the same concern (users) "may not have a chance to
address the issue" . How's that? Users can disable uring, update OS,
kernel and so on.

If I were DBA in the field, I would want to get *any* sort of warning
that connection times are going to be impacted after setting
io_method=uring (WARNING or INFO, doesnt matter, certainly not DEBUG).
IOPS increase probably does not justify the impact to apps with high
values of high max_connections (app connection latency is also often
top concern).  Even OP (Mark) wrote "but when I increase it to =1000
then the time to create a connection almost triples" (and people use
much bigger ones)

We can remove kernel version wording, sure no problem. BTW I'm also a
user and spotted the consequences of lack of this
io_uring_queue_init_mem(3) working on three separate occasions (sic! I
have a short memory), just to realize it's about uring because I've
set up a cluster some time ago and didn't connect the dots after a
while...

today it is:
elog(DEBUG1, "cannot use combined memory mapping for io_uring, ring
creation failed: %m");
elog(DEBUG1, "can't use combined memory mapping for io_uring, kernel
or liburing too old");

So maybe let's just go to the basics and increase DEBUG1->
INFO/NOTICE/WARNING (whatever) and that's all here?

-J.