Re: pgbench: could not connect to server: Resource temporarily unavailable - Mailing list pgsql-performance

From Thomas Munro
Subject Re: pgbench: could not connect to server: Resource temporarily unavailable
Date
Msg-id CA+hUKGLv95LR5o8zgcNNXR9rsAqNPEjrpB4M7O7_bszDHbS6Ug@mail.gmail.com
Whole thread Raw
In response to Re: pgbench: could not connect to server: Resource temporarily unavailable  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgbench: could not connect to server: Resource temporarily unavailable  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-performance
On Tue, Aug 23, 2022 at 4:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 0001 adds a para about how to raise the listen queue length.

+    service the requests, with those clients receiving unhelpful
+    connection failure errors such as <quote>Resource temporarily
+    unavailable</quote>.

LGTM but I guess I would add "... or Connection refused"?

> 0002 isn't quite related, but while writing 0001 I noticed a nearby
> use of /proc/sys/... which I thought should be converted to sysctl.
> IMO /proc/sys pretty much sucks, at least for documentation purposes,
> for multiple reasons:

+1

> 0003 removes PG_SOMAXCONN.  While doing that I noticed that this
> computation hadn't been touched throughout all the various
> changes fooling with exactly what gets counted in MaxBackends.
> I think the most appropriate definition for the listen queue
> length is now MaxConnections * 2, not MaxBackends * 2, because
> the other processes counted in MaxBackends don't correspond to
> incoming connections.

+1

> I propose 0003 for HEAD only, but the docs changes could be
> back-patched.

+1



pgsql-performance by date:

Previous
From: Kevin McKibbin
Date:
Subject: Re: pgbench: could not connect to server: Resource temporarily unavailable
Next
From: Junwang Zhao
Date:
Subject: Re: pgbench: could not connect to server: Resource temporarily unavailable