On Thu, Nov 29, 2012 at 03:33:59PM -0500, Tom Lane wrote: > I wrote: > > So far as I can see, none of the spec-defined EAI_XXX codes map very > > nicely to "path name too long". Possibly we could return EAI_SYSTEM > > and set errno to ENAMETOOLONG, but I'm not sure the latter is very > > portable either. > > I tried this out and found that at least on Linux, gai_strerror() is too > stupid to pay attention to errno anyway; you just get "System error", > which is about as unhelpful as it could possibly be. I don't see any > way that we can get a more specific error message to be printed without > eliminating use of gai_strerror and providing our own infrastructure for > reporting getaddrinfo errors. While that wouldn't be incredibly awful > (we have such infrastructure already for ancient platforms...), it > still kinda sucks.
RFC 2553 and successor standards do not call for gai_strerror() to look at anything other than its argument, so your finding for Linux surprises me less than its alternative. Adopt code like "rc == EAI_SYSTEM ? strerror(errno) : gai_strerror(rc)" to report the error, and your proposal to use ENAMETOOLONG sounds suitable. > > Another line of attack is to just teach getaddrinfo_unix() to malloc its > > result struct big enough to hold whatever the supplied path is. > > I tried this out too, and found that it doesn't work well, because both > libpq and the backend expect to be able to copy getaddrinfo results into > fixed-size SockAddr structs. We could probably fix that by adding > another layer of pointers and malloc operations, but it would be > somewhat invasive. Given the lack of prior complaints it's not clear > to me that it's worth that much trouble --- although getting rid of our > hard-wired assumptions about the maximum result size from getaddrinfo is > attractive from a robustness standpoint. Linux enforces a hard limit matching the static buffer in sockaddr_un. You'd proceed a bit further and hit "could not bind Unix socket: Invalid argument" or some such. I agree we should perhaps fix pg_upgrade to work even when its CWD is not usable as a socket path. It could create a temporary directory under /tmp and place the socket there, for example. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers