From: Tom Lane <tgl@sss.pgh.pa.us>
To: 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: Sun, 21 Aug 2022 22:18:13 -0400
Message-ID: <105986.1661134693@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+hUKGKPyXKf2jrnSUMKc8XvRTYs+kkiZY9GA6nMdMUgLG6EaQ@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>
Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Aug 22, 2022 at 12:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm. It'll be awhile till the 128 default disappears entirely
>> though, especially if assorted BSDen use that too. Probably
>> worth the trouble to document.
> I could try to write a doc patch if you aren't already on it.
I haven't done anything about it yet, but could do so tomorrow or so.
(BTW, I just finished discovering that NetBSD has the same 128 limit.
It looks like they intended to make that settable via sysctl, because
it's a variable not a constant; but they haven't actually wired up the
variable to sysctl yet.)
> Oh, right. Looks like that was just paranoia in commit 153f4006763,
> back when you got away from using the (very conservative) SOMAXCONN
> macro. Looks like that was 5 on ancient systems going back to the
> original sockets stuff, and later 128 was a popular number. Yeah I'd
> say +1 for removing our cap. I'm pretty sure every system will
> internally cap whatever value we pass in if it doesn't like it, as
> POSIX explicitly says it can freely do with this "hint".
Yeah. I hadn't thought to check the POSIX text, but their listen(2)
page is pretty clear that implementations should *silently* reduce
the value to what they can handle, not fail. Also, SUSv2 says the
same thing in different words, so the requirement's been that way
for a very long time. I think we could drop this ancient bit of
paranoia.
> ... Hmm, maybe we could add a hint to the error,
> though?
libpq doesn't really have a notion of hints --- perhaps we ought
to fix that sometime. But this doesn't seem like a very exciting
place to start, given the paucity of prior complaints. (And anyway
people using other client libraries wouldn't be helped.) I think
some documentation in the "Managing Kernel Resources" section
should be plenty for this.
regards, tom lane
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, 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: <105986.1661134693@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