Just curious, *backlog* defines the maximum pending connections, why do we need to double the MaxConnections as the queue size? It seems *listen* with larger *backlog* will tell the OS maintain a larger buffer? - maxconn = MaxBackends * 2; - if (maxconn > PG_SOMAXCONN) - maxconn = PG_SOMAXCONN; + maxconn = MaxConnections * 2; On Tue, Aug 23, 2022 at 12:57 AM Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > > OK, here's some proposed patches. > > 0001 adds a para about how to raise the listen queue length. > > 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: > > * It's unlike the way you do things on other platforms. > > * "man sysctl" will lead you to useful documentation about how to > use that command. There's no obvious way to find documentation > about /proc/sys. > > * It's not at all sudo-friendly. Compare > sudo sh -c 'echo 0 >/proc/sys/kernel/randomize_va_space' > sudo sysctl -w kernel.randomize_va_space=0 > The former is a lot longer and it's far from obvious why you have > to do it that way. > > * You have to think in sysctl terms anyway if you want to make the > setting persist across reboots, which you almost always do. > > * Everywhere else in runtime.sgml, we use sysctl not /proc/sys. > > 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. > > I propose 0003 for HEAD only, but the docs changes could be > back-patched. > > regards, tom lane > -- Regards Junwang Zhao
