Thomas Munro <thomas.munro@gmail.com> writes:
> If it's something like that, maybe increasing
> /proc/sys/net/core/somaxconn would help? I think older kernels only
> had 128 here.
Bingo! I see
$ cat /proc/sys/net/core/somaxconn
128
by default, which is right about where the problem starts. After
$ sudo sh -c 'echo 1000 >/proc/sys/net/core/somaxconn'
*and restarting the PG server*, I can do a lot more threads without
a problem. Evidently, the server's socket's listen queue length
is fixed at creation and adjusting the kernel limit won't immediately
change it.
So what we've got is that EAGAIN from connect() on a Unix socket can
mean "listen queue overflow" and the kernel won't treat that as a
nonblock-waitable condition. Still seems like a kernel bug perhaps,
or at least a misfeature.
Not sure what I think at this point about making libpq retry after
EAGAIN. It would make sense for this particular undocumented use
of EAGAIN, but I'm worried about others, especially the documented
reason. On the whole I'm inclined to leave the code alone;
but is there sufficient reason to add something about adjusting
somaxconn to our documentation?
regards, tom lane
