Re: pgbench: could not connect to server: Resource temporarily unavailable - Mailing list pgsql-performance

From Junwang Zhao
Subject Re: pgbench: could not connect to server: Resource temporarily unavailable
Date
Msg-id CAEG8a3L=7gVapJoGaFQWu83MvDAebe6SswjWKeoXdb66vxDA=Q@mail.gmail.com
Whole thread Raw
In response to Re: pgbench: could not connect to server: Resource temporarily unavailable  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgbench: could not connect to server: Resource temporarily unavailable
Next
From: Tom Lane
Date:
Subject: Re: pgbench: could not connect to server: Resource temporarily unavailable