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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Junwang Zhao <zhjwpku(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Kevin McKibbin <kevinmckibbin123(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: pgbench: could not connect to server: Resource temporarily unavailable
Date: 2022-08-23 03:37:43
Message-ID: 476557.1661225863@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Junwang Zhao <zhjwpku(at)gmail(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Junwang Zhao 2022-08-23 03:46:12 Re: pgbench: could not connect to server: Resource temporarily unavailable
Previous Message Junwang Zhao 2022-08-23 03:12:07 Re: pgbench: could not connect to server: Resource temporarily unavailable