Hi, On 2023-01-23 01:20:54 -0500, Tom Lane wrote: > Michael Paquier <mich...@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.7xjiwdg3gvb62...@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