On 2015-08-06 12:05:24 -0300, Alvaro Herrera wrote:
> 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.
I had to split of three things: LOCKMASK, the individual lock levels and
xl_standby_lock to be able to prohibit lock.h to be included by frontend
code. lockdefs.h works for me, counter proposals?
There weren't any places that needed additional lock.h includes. But
hashfn.c somewhat hilariously missed utils/hsearch.h ;)
Regards,
Andres