Andres Freund wrote:
> On 2015-08-06 10:27:52 -0400, Tom Lane wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > >> One approach is to avoid including lwlock.h/slot.h in frontend
> > >> code. That'll require some minor surgery and adding a couple includes,
> > >> but it doesn't look that bad.
> >
> > > Patch doing that attached.
> >
> > This seems kinda messy. Looking at the contents of lock.h, it seems like
> > getting rid of its dependency on lwlock.h is not really very appropriate,
> > because there is boatloads of other backend-only stuff in there. Why is
> > any frontend code including lock.h at all? If there is a valid reason,
> > should we refactor lock.h into two separate headers, one that is safe to
> > expose to frontends and one with the rest of the stuff?
>
> I think the primary reason for lock.h being included pretty widely is to
> have the declaration of LOCKMODE. That's pretty widely used in headers
> included by clients for various reasons. There's also a bit of fun
> around xl_standby_locks.
I think it is a good idea to split up LOCKMODE so that most headers do
not need to include lock.h at all; you will need to add an explicit
#include "storage/lock.h" to a lot of C files, but to me that's a good
thing.
See
http://doxygen.postgresql.org/lock_8h.html
Funnily enough, the "included by" graph is so large that my browser
(arguably a bit dated) fails to display it and shows a black rectangle
instead. Chromium shows it, though it's illegible.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
