Re: pgbench: could not connect to server: Resource temporarily unavailable
| От | Thomas Munro |
|---|---|
| Тема | Re: pgbench: could not connect to server: Resource temporarily unavailable |
| Дата | |
| Msg-id | CA+hUKGLv95LR5o8zgcNNXR9rsAqNPEjrpB4M7O7_bszDHbS6Ug@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pgbench: could not connect to server: Resource temporarily unavailable (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: pgbench: could not connect to server: Resource temporarily unavailable
|
| Список | 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 по дате отправления: