Thomas Munro <thomas.munro@xxxxxxxxx> writes: > On Mon, Aug 22, 2022 at 12:20 PM Tom Lane <tgl@xxxxxxxxxxxxx> 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
