From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Fix thinko in previous commit |
Date: | 2012-10-09 17:07:36 |
Message-ID: | 25905.1349802456@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> 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.
I'd not tried a build with plpython on my old HPUX box recently, but
looking into its Python headers I find
$ grep -r USE_INLINE /usr/local/include/python2.5
/usr/local/include/python2.5/pyport.h:#undef USE_INLINE /* XXX - set via configure? */
/usr/local/include/python2.5/pyport.h:#elif defined(USE_INLINE)
which means on this box things would have failed in the opposite
direction (undefined references to non-provided external functions)
without the rename. So that's the right fix for sure.
>> 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.
The more I think about that, the more worried I get. It's not just
that _POSIX_C_SOURCE might be defined or not, it's that the *value*
it has affects what definitions you get. At least that's how it
looks on my box. So our existing code potentially allows Python.h
to redefine it with a different value than what we'd defined it as,
which could result in inconsistencies between the system headers
included by postgres.h and those included later. I think this needs
reconsideration. Not sure what to do about it exactly, though :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-10-09 20:38:09 | pgsql: Remove unnecessary overhead in backend's large-object operations |
Previous Message | Heikki Linnakangas | 2012-10-09 16:35:06 | pgsql: Fix silly bug in previous refactoring. |