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