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

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: Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)
Date: 2012-11-29 22:20:25
Message-ID: 18563.1354227625@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/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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Noah Misch 2012-11-29 22:36:32 Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)
Previous Message Simon Riggs 2012-11-29 22:18:49 pgsql: Cleanup VirtualXact at end of Hot Standby

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2012-11-29 22:36:32 Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)
Previous Message Andrew Dunstan 2012-11-29 22:14:14 Re: json accessors