pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Junwang Zhao <zhjwpku@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Kevin McKibbin <kevinmckibbin123@gmail.com>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: pgbench: could not connect to server: Resource temporarily unavailable
Date: Mon, 22 Aug 2022 23:37:43 -0400
Message-ID: <476557.1661225863@sss.pgh.pa.us> (raw)
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>

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





view thread (27+ messages)  latest in thread

Message-ID: <476557.1661225863@sss.pgh.pa.us>
Permalink:  ../476557.1661225863@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/476557.1661225863@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, zhjwpku@gmail.com, thomas.munro@gmail.com, andrew@dunslane.net, kevinmckibbin123@gmail.com, pgsql-performance@lists.postgresql.org
  Subject: Re: pgbench: could not connect to server: Resource temporarily unavailable
  In-Reply-To: <476557.1661225863@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox