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

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 (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-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

pgsql-hackers by date

Next:From: Noah MischDate: 2012-11-29 22:36:32
Subject: Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactorflex and bison make rules)
Previous:From: Andrew DunstanDate: 2012-11-29 22:14:14
Subject: Re: json accessors

pgsql-committers by date

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

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