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: Noah Misch <noah(at)leadboat(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 14:13:40
Message-ID: 20150807141340.GU2441@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund wrote:

> > 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 argued that way as well upthread. But I do think that Tom has a good
> point when he argues that frontend code really has no business including
> lock.h in total. The only reason we need it is because a few headers we
> need to include have LOCKMODE parameters and/or contain macros that
> refer to lock levels. So I do think that having a version that doesn't
> expose any unnecessary details is a good idea.
>
> > With that, indirect frontend lock.h inclusion will work fine.
>
> But there seems little reason trying to support doing so. It's not very
> hard to imagine that lock.c and by extension lock.h get more complicated
> in the future as it's already a scalability bottleneck. that very well
> might require including atomics, spinlocks and the like in lock.h.

I don't disagree with any of your points, but nevertheless I think the
split suggested by Noah is a good one (it's more principled than the one
you suggest, at any rate) and perhaps it would be a good compromise to
do both things in a fell swoop.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2015-08-07 14:30:45 Re: Reduce ProcArrayLock contention
Previous Message Robert Haas 2015-08-07 14:09:01 Re: Race conditions in shm_mq.c