Re: Raising our compiler requirements for 9.6

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 03:23:43
Message-ID: 20150807032343.GA1813690@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 06, 2015 at 05:34:50PM +0200, Andres Freund wrote:
> On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > @@ -0,0 +1,56 @@
> > > +/*-------------------------------------------------------------------------
> > > + *
> > > + * lockdefs.h
> > > + * Frontend exposed parts of postgres' low level lock mechanism
> > > + *
> > > + * The split between lockdefs.h and lock.h is not very principled.
> >
> > No kidding!
>
> Do you have a good suggestion about the split? I wanted to expose the
> minimal amount necessary, and those were the ones.

lock.h includes lwlock.h only for the benefit of the three LockHashPartition*
macros. Those macros are pieces of the lock.c implementation that cross into
proc.c, not pieces of the lock.c public API. I suggest instead making a
lock_internals.h for those macros and for anything else private to the various
files of the lock implementation. For example, the PROCLOCK struct and the
functions that take arguments of that type would fit in lock_internals.h.
With that, indirect frontend lock.h inclusion will work fine.

Thanks,
nm

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-08-07 04:41:46 Re: Reduce ProcArrayLock contention
Previous Message Tom Lane 2015-08-07 03:22:39 Re: pgsql: Fix BRIN to use SnapshotAny during summarization