Hi Andres,
On Sun, Sep 21, 2025 at 6:29 PM Andres Freund <andres@anarazel.de> wrote:
[..]
> This seems too low-level for end user docs, while not explaining that the
> impact is due to a high max_connections value, rather than a large number of
> actually established connections. How about something like
>
> Note that for optimal performance with <literal>io_uring</literal> Linux
> kernel version >= 6.5 is recommended. Older Linux versions, high values
> of <xref linkend="guc-max-connections"/> will slow down connection
> establishment and termination.
Agreed, attached v2. Just one nitpick -- wouldn't '>> On << older
Linux versions ' sound better there?
[..v1 patch]
>
> To me this seems too verbose, particularly because the majority of users
> encountering it have zero chance to address the issue. And it's not like most
> real world workloads are particularly affected, if you run with
> max_connections=20k and have 100/connections second, you'll have a *lot* of
> other problems.
> Here's the full log of a start with the fallback branch forced:
[..]
> Close to half the lines are the new warning.
I see two paths forward:
1. either we make it shorter, but I do not know if a multi-sentence
error message isn't against some project's policy? Feel free to
readjust as necessary, I'm not strongly attached to the exact wording
, just to hint people.
2. maybe we could emit the warning only in certain criteria, like
if(max_connections>1000) for example. However Mark (OP) reported it
even for the value of 100 so it seems we should warn about it like
always? (and it deteriorated 3x for him @ 1000 max_connections), so
it's like opening a new can of worms (to establish a proper
threshold).
Anyway attached v2 generates:
2025-09-22 09:56:21.123 CEST [12144] WARNING: io_uring combined
memory mapping creation failed: Unknown error -8192. Upgrade kernel to
6.5+ for improved performance
2025-09-22 09:56:21.179 CEST [12144] LOG: starting PostgreSQL 19devel
on x86_64-linux, compiled by clang-16.0.6, 64-bit
2025-09-22 09:56:21.180 CEST [12144] LOG: listening on IPv6 address
"::1", port 1236
2025-09-22 09:56:21.180 CEST [12144] LOG: listening on IPv4 address
"127.0.0.1", port 1236
2025-09-22 09:56:21.185 CEST [12144] LOG: listening on Unix socket
"/tmp/.s.PGSQL.1236"
2025-09-22 09:56:21.197 CEST [12147] LOG: database system was shut
down at 2025-09-22 09:55:44 CEST
2025-09-22 09:56:21.207 CEST [12144] LOG: database system is ready to
accept connections
BTW: on RHEL/derivatives it was possible to push people in certain
critical conditions into using kernel-lt/kernel-ml (but that's from
EPEL repos) , so it's not that they do not have space for maneuver.
-J.
