Hi,
On 2023-01-23 01:20:54 -0500, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
> > On Sat, Jan 21, 2023 at 05:25:19AM +0000, Andres Freund wrote:
> >> instr_time: Represent time as an int64 on all platforms
>
> > hoverfly is unhappy since this went in:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hoverfly&dt=2023-01-23%2005%3A01%3A44
>
> Yeah, there was some discussion about that already:
>
> https://www.postgresql.org/message-id/20230121190303.7xjiwdg3gvb62lu3@awork3.anarazel.de
I was thinking of starting a starting a separate thread about it - it's
mostly a plpython issue, the fact that my commit caused the compilation
failure is somewhat random.
Although I now wonder if we could solve the issue of the compilation failure
in a localized way, separately from fixing plpython. There's really no need
for execnodes to include instrumentation.h (and thus instr_time). With a
forward define of struct Instrumentation and WorkerInstrumentation (and using
it in the file), plpython builds just fine with an intentionally broken
instr_time.h.
> I'm inclined to think that we should fix the plpython code to be rigorous
> about including everything else we need before including the Python
> headers. That's ugly, but it's not our fault that Python thinks it can
> redefine _POSIX_C_SOURCE.
Another approach could be to figure out that we ought to define
_POSIX_C_SOURCE when building files that involve plpython (e.g. by querying
the define during configure). But I'm a bit worried about that breaking
assumptions we make - we do define _GNU_SOURCE on linux via CPPFLAGS, and IIRC
there are some weird conflicts between the two.
Greetings,
Andres Freund
