Re: Raising our compiler requirements for 9.6

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-06 15:05:24
Message-ID: 20150806150524.GM2441@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund wrote:
> On 2015-08-06 10:27:52 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > >> One approach is to avoid including lwlock.h/slot.h in frontend
> > >> code. That'll require some minor surgery and adding a couple includes,
> > >> but it doesn't look that bad.
> >
> > > Patch doing that attached.
> >
> > This seems kinda messy. Looking at the contents of lock.h, it seems like
> > getting rid of its dependency on lwlock.h is not really very appropriate,
> > because there is boatloads of other backend-only stuff in there. Why is
> > any frontend code including lock.h at all? If there is a valid reason,
> > should we refactor lock.h into two separate headers, one that is safe to
> > expose to frontends and one with the rest of the stuff?
>
> I think the primary reason for lock.h being included pretty widely is to
> have the declaration of LOCKMODE. That's pretty widely used in headers
> included by clients for various reasons. There's also a bit of fun
> around xl_standby_locks.

I think it is a good idea to split up LOCKMODE so that most headers do
not need to include lock.h at all; you will need to add an explicit
#include "storage/lock.h" to a lot of C files, but to me that's a good
thing.

See
http://doxygen.postgresql.org/lock_8h.html
Funnily enough, the "included by" graph is so large that my browser
(arguably a bit dated) fails to display it and shows a black rectangle
instead. Chromium shows it, though it's illegible.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-08-06 15:21:19 Re: Raising our compiler requirements for 9.6
Previous Message Stephen Frost 2015-08-06 14:46:03 Re: nodes/*funcs.c inconsistencies