Thomas Munro <thomas.munro@xxxxxxxxx> 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
