On 2014-04-24 11:02:44 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
