On Mon, Jan 6, 2014 at 5:50 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> This is only part of the solution, of course: a complete solution will
> involve making the hash table key something other than the lock ID.
> What I'm thinking we can do is making the lock ID consist of two
> unsigned 32-bit integers. One of these will be stored in the lwlock
> itself, which if my calculations are correct won't increase the size
> of LWLockPadded on any common platforms (a 64-bit integer would).
> Let's call this the "tranch id". The other will be derived from the
> LWLock address. Let's call this the "instance ID". We'll keep a
> table of tranch IDs, which will be assigned consecutively starting
> with 0. We'll keep an array of metadata for tranches, indexed by
> tranch ID, and each entry will have three associated pieces of
> information: an array base, a stride length, and a printable name.
> When we need to identify an lwlock in the log or to dtrace, we'll
> fetch the tranch ID from the lwlock itself and use that to index into
> the tranch metadata array. We'll then take the address of the lwlock,
> subtract the array base address for the tranch, and divide by the
> stride length; the result is the instance ID. When reporting the
> user, we can report either the tranch ID directly or the associated
> name for that tranch; in either case, we'll also report the instance
> ID.
>
> So initially we'll probably just have tranch 0: the main LWLock array.
> If we move buffer content and I/O locks to the buffer headers, we'll
> define tranch 1 and tranch 2 with the same base address: the start of
> the buffer descriptor array, and the same stride length, the size of a
> buffer descriptor. One will have the associated name "buffer content
> lock" and the other "buffer I/O lock". If we want, we can define
> split the main LWLock array into several tranches so that we can more
> easily identify lock manager locks, predicate lock manager locks, and
> buffer mapping locks.
OK, I've implemented this: here's what I believe to be a complete
patch, based on the previous lwlock-pointers.patch but now handling
LOCK_DEBUG and TRACE_LWLOCKS and dtrace and a bunch of other loose
ends. I think this should be adequate for allowing lwlocks to be
stored elsewhere in the main shared memory segment as well as in
dynamic shared memory segments.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
