Andres Freund wrote: > On 2015-08-06 10:27:52 -0400, Tom Lane wrote: > > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
