Andrew Dunstan <andrew@xxxxxxxxxxxx> writes: > On 2022-08-21 Su 17:15, Tom Lane wrote: >> On the whole this is smelling more like a Linux kernel bug than >> anything else. > *nod* Conceivably we could work around this in libpq: on EAGAIN, just retry the failed connect(), or maybe better to close the socket and take it from the top with the same target server address. On the one hand, reporting EAGAIN certainly sounds like an invitation to do just that. On the other hand, if the failure is persistent then libpq is locked up in a tight loop --- and "Insufficient entries in the routing cache" doesn't seem like a condition that would clear immediately. It's also pretty unclear why the kernel would want to return EAGAIN instead of letting the nonblock connection path do the waiting, which is why I'm suspecting a bug rather than designed behavior. I think I'm disinclined to install such a workaround unless we get confirmation from some kernel hacker that it's operating as designed and application-level retry is intended. regards, tom lane