Horton

Re: pgbench: could not connect to server: Resource temporarily unavailable

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Junwang Zhao <zhjwpku@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Kevin McKibbin <kevinmckibbin123@gmail.com>, pgsql-performance@lists.postgresql.org
Date: 2022-08-23T03:37:43Z
Lists: pgsql-performance 
Junwang Zhao <zhjwpku@gmail.com> writes:
> Just curious, *backlog* defines the maximum pending connections,
> why do we need to double the MaxConnections as the queue size?

The postmaster allows up to twice MaxConnections child processes
to exist, per the comment in canAcceptConnections:

     * We allow more connections here than we can have backends because some
     * might still be authenticating; they might fail auth, or some existing
     * backend might exit before the auth cycle is completed.  The exact
     * MaxBackends limit is enforced when a new backend tries to join the
     * shared-inval backend array.

You can argue that 2X might not be the right multiplier, and you
can argue that the optimal listen queue length might be more or
less than the limit on number of child processes, but that's how
we've historically done it.  I'm not especially interested in
changing that without somebody making a well-reasoned case for
some other number.

			regards, tom lane

Commits

  1. Doc: document possible need to raise kernel's somaxconn limit.

  2. Doc: prefer sysctl to /proc/sys in docs and comments.

  3. Remove our artificial PG_SOMAXCONN limit on listen queue length.

  4. Instead of believing SOMAXCONN from the system header files (which is