Re: Raising our compiler requirements for 9.6

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Raising our compiler requirements for 9.6
Date: 2015-08-07 18:38:44
Message-ID: 20150807183844.GH4916@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-08-07 14:32:35 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > Well, I just work here, but it seems silly to me to reorgnize the
> > headers so that you can include fewer definitions where necessary, but
> > then not revise the existing headers to use the slimmed-down versions
> > where possible. Yeah, somebody might have to adjust their #includes
> > and that is annoying, but I don't think the cost of your new #error
> > directives is going to be zero.
>
> I'm a bit concerned about that too; what it means is that any addition
> of new #includes in backend header files carries a nontrivial risk of
> breaking frontend code that used to be fine (at least on most platforms).
> As an example, the proximate cause of the pademelon breakage was that
> pg_resetxlog needs to #include tuptoaster.h to get TOAST_MAX_CHUNK_SIZE.
> That was perfectly safe up till commit 2ef085d0e6960f50, when somebody
> semi-randomly decided that it'd be a good idea to declare a function
> taking a LOCKMODE argument in that header.
>
> Eventually I think we're going to have to spend some effort on making a
> clearer separation between "front end safe" and "not front end safe"
> header files. Until we do that, though, adding these #error directives
> may just do more harm than good. We don't know which backend headers
> are being used by third-party code, but we can be 100% sure it's more
> than what's used by the frontend code in the core distribution.

Right now the #errors are in only in places that'd also break without
them, but only on the old platforms without inline support and in a more
subtle way.

I'm ok with getting lock.h from the list of headers where that's the
case, done by removing lwlock.h from it, which I proposed that
upthread. But then you objected to that approach.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-08-07 18:43:11 Re: 9.5 release notes
Previous Message Tom Lane 2015-08-07 18:32:35 Re: Raising our compiler requirements for 9.6