From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Kevin McKibbin <kevinmckibbin123(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgbench: could not connect to server: Resource temporarily unavailable |
Date: | 2022-08-23 02:42:13 |
Message-ID: | CA+hUKGLv95LR5o8zgcNNXR9rsAqNPEjrpB4M7O7_bszDHbS6Ug@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Aug 23, 2022 at 4:57 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Junwang Zhao | 2022-08-23 03:12:07 | Re: pgbench: could not connect to server: Resource temporarily unavailable |
Previous Message | Kevin McKibbin | 2022-08-22 21:14:23 | Re: pgbench: could not connect to server: Resource temporarily unavailable |