Re: slow startup due to LWLockAssign() spinlock

On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-04-24 15:56:45 +0300, Heikki Linnakangas wrote:
> >> Another idea is to add an LWLockAssignBatch(int) function that assigns a
> >> range of locks in one call. That would be very simple, and I think it would
> >> be less likely to break things than a new global flag. I would be OK with
> >> sneaking that into 9.4 still.
>
> > I don't really see the advantage tbh. Assuming we always can avoid the
> > spinlock initially seems simple enough - and I have significant doubts
> > that anything but buffer locks will need enough locks that it matters
> > for other users.
>
> FWIW, I like the LWLockAssignBatch idea a lot better than the currently
> proposed patch. LWLockAssign is a low-level function that has no business
> making risky assumptions about the context it's invoked in.

I don't think LWLockAssignBatch() is that easy without introducing
layering violations. It can't just return a pointer out of the main
lwlock array that then can be ++ed clientside because MainLWLockArray's
stride isn't sizeof(LWLock).
We could just add a LWLockAssignStartup(), that'd be pretty
trivial. Whoever uses it later gets to keep the pieces...

I guess if it's not that, the whole thing is 9.5 material. Once those
locks are in a separate tranche the whole thing is moot anyway.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services