From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Jeremy Drake <pgbuildfarm(at)jdrake(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) |
Date: | 2012-11-29 22:36:32 |
Message-ID: | 20121129223632.GA15016@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-11-29 23:00:30 | Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) |
Previous Message | Tom Lane | 2012-11-29 22:20:25 | Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-11-29 23:00:30 | Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) |
Previous Message | Tom Lane | 2012-11-29 22:20:25 | Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) |