On 2015-08-06 23:23:43 -0400, Noah Misch wrote:
> On Thu, Aug 06, 2015 at 05:34:50PM +0200, Andres Freund wrote:
> > On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
> > > Andres Freund wrote:
> > > > @@ -0,0 +1,56 @@
> > > > +/*-------------------------------------------------------------------------
> > > > + *
> > > > + * lockdefs.h
> > > > + * Frontend exposed parts of postgres' low level lock mechanism
> > > > + *
> > > > + * The split between lockdefs.h and lock.h is not very principled.
> > >
> > > No kidding!
> >
> > Do you have a good suggestion about the split? I wanted to expose the
> > minimal amount necessary, and those were the ones.
>
> 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.
Greetings,
Andres Freund
