Andrew Dunstan <andrew@dunslane.net> writes:
> On 11/29/2012 03:33 PM, Tom Lane wrote:
>>> 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 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.
I'm thinking maybe we should try to fix this. What's bugging me is that
Jeremy's build path doesn't look all that unreasonably long. The scary
scenario that's in the back of my mind is that one day somebody decides
to rearrange the Red Hat build servers a bit and suddenly I can't build
Postgres there anymore, because the build directory is nested a bit too
deep. Murphy's law would of course dictate that I find this out only
when under the gun to get a security update packaged.
regards, tom lane
