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
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 |