Horton

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

Junwang Zhao <zhjwpku@gmail.com>

View thread View on postgr.es
From: Junwang Zhao <zhjwpku@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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:46:12Z
Lists: pgsql-performance 
Ok, thanks for the clarification.

On Tue, Aug 23, 2022 at 11:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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



-- 
Regards
Junwang Zhao

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