From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Jeremy Drake <pgbuildfarm(at)jdrake(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) |
Date: | 2012-11-29 16:31:30 |
Message-ID: | 24123.1354206690@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 11/28/2012 11:03 PM, Tom Lane wrote:
>> [ digs around ... ] It looks like the failure is coming from here:
>>
>> if (strlen(path) >= sizeof(unp->sun_path))
>> return EAI_FAIL;
> Looks like it was. Good catch. What's the best way to fix?
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.
Another line of attack is to just teach getnameinfo_unix() to malloc its
result struct big enough to hold whatever the supplied path is. The
portability risk here is if sun_path is not the last field in struct
sockaddr_un on some platform --- but that seems a bit unlikely, and even
if it isn't I doubt we access any other members besides sun_family and
sun_path. I kind of like this approach, since it gets rid of the
length limitation rather than just reporting it more clearly.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-11-29 19:52:53 | pgsql: Fix assorted bugs in CREATE INDEX CONCURRENTLY. |
Previous Message | Andrew Dunstan | 2012-11-29 16:17:44 | Re: [COMMITTERS] pgsql: Refactor flex and bison make rules |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-11-29 16:53:50 | Re: Bugs in CREATE/DROP INDEX CONCURRENTLY |
Previous Message | Andrew Dunstan | 2012-11-29 16:17:44 | Re: [COMMITTERS] pgsql: Refactor flex and bison make rules |