Skip site navigation (1) Skip section navigation (2)

Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 21:24:13
Message-ID: 50B7D27D.20501@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On 11/29/2012 03:33 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> 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.
> 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.
>
>> 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.
>
> I'm a bit tempted to just replace EAI_FAIL with EAI_MEMORY here, so
> that you'd get messages similar to "Memory allocation failure".  That
> might at least point your thoughts in the right direction, whereas
> "Non-recoverable failure in name resolution" certainly conveys nothing
> of use.
>
> Thoughts?


I don't think it's worth a heroic effort. Meanwhile I'll add a check in 
the upgrade test module(s) to check for overly long paths likely to give 
problems.

cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Andres FreundDate: 2012-11-29 21:49:57
Subject: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
Previous:From: Tom LaneDate: 2012-11-29 20:33:59
Subject: Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)

pgsql-committers by date

Next:From: Simon RiggsDate: 2012-11-29 22:00:30
Subject: pgsql: Cleanup VirtualXact at end of Hot Standby.
Previous:From: Tom LaneDate: 2012-11-29 20:33:59
Subject: Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group