Re: pgsql: Fix thinko in previous commit
От | Alvaro Herrera |
---|---|
Тема | Re: pgsql: Fix thinko in previous commit |
Дата | |
Msg-id | 20121009122009.GB4214@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: pgsql: Fix thinko in previous commit (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Fix thinko in previous commit
|
Список | pgsql-committers |
Tom Lane wrote: > I wrote: > > But having said that, it seems there's something wrong with the > > STATIC_IF_INLINE patch for the case where USE_INLINE doesn't get set. > > I'm too tired to investigate right now, but if you manually disable > > USE_INLINE in pg_config.h after configuring, do you see a problem? > > I summoned the energy to run a build with an old non-inline-aware > C compiler, and it went through, so the explanation is not that > simple. Yeah, I had tried that, sorry for not making it explicit. > Looking again at the spoonbill failure, it's striking that it gets as > far as plpython before choking. The symptoms are consistent with the > theory that USE_INLINE is getting #define'd by some Python header or > other, after having *not* been defined by pg_config.h. Maybe we should > rename that to PG_USE_INLINE? Ahh, that makes a lot of sense, yes; and I see that the Python headers in my machine do mention USE_INLINE (though this is not defined, even on pyconfig.h), so it is indeed possible that on some other machines it is defined somewhere in those headers. I will go rename ours. Thanks for the research. > BTW, just noticing that this theory espoused in plpython.h: > > * Undefine some things that get (re)defined in the Python headers. They aren't > * used by the PL/Python code, and all PostgreSQL headers should be included > * earlier, so this should be pretty safe. > > is entirely full of it, as the plpy_*.h files feel free to pull in > random Postgres header files. Maybe that area needs another look. > It's (probably) not contributing to this particular breakage, but I > can't say that I think undef'ing things like _POSIX_C_SOURCE midstream > is a bright idea at all. Seems to me that could easily result in > inconsistent results from reading different system header files. Ugh. I notice that this seems to be a recent development; I think it only started with 147c2482 (and I made it worse at 0a664ec2 and c219d9b0). Maybe we should just clean that up a bit. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-committers по дате отправления: