Re: pgsql: Fix thinko in previous commit

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Fix thinko in previous commit
Date: 2012-10-09 12:20:09
Message-ID: 20121009122009.GB4214@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2012-10-09 15:02:16 pgsql: Rename USE_INLINE to PG_USE_INLINE
Previous Message Heikki Linnakangas 2012-10-09 10:07:01 pgsql: Remove stray newline in comment.