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
Subject: Re: pgbench: could not connect to server: Resource temporarily
 unavailable
In-reply-to: 
 <CAEG8a3Km3Yyy3VpOcYXjw+CYphF+GrkGs-g7cuu8LiJsvO0eEA@mail.gmail.com>
References: 
 <CADc_NKg2d+oZY9mg4DdQdoUcGzN2kOYXBu-3--RW_hEe0tUV=g@mail.gmail.com>
 <3909995.1661052002@sss.pgh.pa.us>
 <35d221aa-3da4-f744-3965-ceca7f71f4ea@dunslane.net>
 <8864.1661116501@sss.pgh.pa.us>
 <83134bb1-3a21-059f-1cd6-4997de2652b8@dunslane.net>
 <33898.1661118503@sss.pgh.pa.us>
 <CA+hUKGLTNSJrKYByirsSyqodmp28McpNUCL5-gvCLXtOj0RwBQ@mail.gmail.com>
 <68893.1661122531@sss.pgh.pa.us>
 <CA+hUKG+MxvFtEYFeSfJZoUUmNSR=fZ=fffWUshU8eLg+CFki+A@mail.gmail.com>
 <84184.1661127637@sss.pgh.pa.us>
 <CA+hUKGKPyXKf2jrnSUMKc8XvRTYs+kkiZY9GA6nMdMUgLG6EaQ@mail.gmail.com>
 <105986.1661134693@sss.pgh.pa.us>
 <CA+hUKGLP80EUDitSKLfgr1rS2pBtr91VY-3GuTbduYPkQ+DYwQ@mail.gmail.com>
 <114075.1661136913@sss.pgh.pa.us> <361175.1661187463@sss.pgh.pa.us>
 <CAEG8a3Km3Yyy3VpOcYXjw+CYphF+GrkGs-g7cuu8LiJsvO0eEA@mail.gmail.com>
Comments: In-reply-to Junwang Zhao <zhjwpku@gmail.com>
	message dated "Tue, 23 Aug 2022 11:12:07 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <476556.1661225863.1@sss.pgh.pa.us>
Date: Mon, 22 Aug 2022 23:37:43 -0400
Message-ID: <476557.1661225863@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/476557.1661225863%40sss.pgh.pa.us>
Precedence: bulk

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