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 can have a go at trying to separate them, but I'm not convinced it's going to look particularly pretty. > Also, I think the reason for the #include is that lock.h has a couple > of macros that reference MainLWLockArray. The fact that you can omit > the #include lwlock.h is therefore only accidental: if we had done those > as static inline functions, this wouldn't work at all. So I think this > solution is not very future-proof either. Yea, I saw that and concluded I'm not particularly bothered by it. Most of the other similar macros are in lwlock.h itself, and if it became a problem we could just move them alongside. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
