Re: Raising our compiler requirements for 9.6

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Raising our compiler requirements for 9.6
Дата
Msg-id 20150807032343.GA1813690@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: Raising our compiler requirements for 9.6  (Andres Freund <andres@anarazel.de>)
Ответы Re: Raising our compiler requirements for 9.6
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Autonomous Transaction is back
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Reduce ProcArrayLock contention