On 2014-04-24 12:43:13 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-04-24 11:02:44 -0400, Tom Lane wrote: > >> 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). > > Meh. I knew this business of using pointers instead of indexes would > have some downsides. > > We could return the array stride ... kinda ugly, but since there's > probably only one consumer for this API, it's not *that* bad. Could > wrap the stride-increment in a macro, perhaps.
I think I am just going to wait for 9.5 where I sure hope we can allocate the buffer lwlocks outside the main array... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers