On Mon, Aug 22, 2022 at 10:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?
My Debian system apparently has a newer man page:
EAGAIN For nonblocking UNIX domain sockets, the socket is nonblocking,
and the connection cannot be completed immediately. For other
socket families, there are insufficient entries in the routing
cache.
Yeah retrying doesn't seem that nice. +1 for a bit of documentation,
which I guess belongs in the server tuning part where we talk about
sysctls, perhaps with a link somewhere near max_connections? More
recent Linux kernels bumped it to 4096 by default so I doubt it'll
come up much in the future, though. Note that we also call listen()
with a backlog value capped to our own PG_SOMAXCONN which is 1000. I
doubt many people benchmark with higher numbers of connections but
it'd be nicer if it worked when you do...
I was curious and checked how FreeBSD would handle this. Instead of
EAGAIN you get ECONNREFUSED here, until you crank up
kern.ipc.somaxconn, which also defaults to 128 like older Linux.