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)
|
Список | 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 по дате отправления: