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

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)
Дата
Msg-id 50B7EB27.4040007@dunslane.net
обсуждение исходный текст
Ответ на Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 11/29/2012 05:20 PM, Tom Lane wrote:
>> 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.
>
>             

The only thing it breaks AFAIK is pg_upgrade testing because pg_upgrade 
insists on setting the current directory as the socket dir. Maybe we 
need a pg_upgrade option to specify the socket dir to use. Or maybe the 
postmaster needs to check the length somehow before it calls 
StreamServerPort() so we can give a saner error message.

cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)