* Robert Haas (robertmh...@gmail.com) wrote: > Another idea is to include some identifying information in the lwlock.
That was my immediate reaction to this issue... > For example, each lwlock could have a char *name in it, and we could > print the name. In theory, this could be a big step forward in terms > of usability, because it'd spare us all needing to remember that 4 == > ProcArrayLock. But it's awkward for buffer locks, of which there > might be a great many, and we surely don't want to allocate a > dynamically-generated string in shared memory for each one. You could > do a bit better by making the identifying information a string plus an > integer, because then all the buffer locks could set the string to a > static constant like "buffer content lock" and the integer to the > buffer number, and similarly for lock manager partition locks and so > on. This is appealing, but would increase the size of LWLockPadded > from 16 bytes to 32 on 64-bit platforms where slock_t is four bytes or > less, which I'm not that excited about even though it would reduce > cache line contention in some cases. I'm not thrilled with this either but at the same time, it may well be worth it. > Yet a third idea is to try to reverse-engineer a name for a given > lwlock from the pointer address. If it's an offset into the main > array, this is easy enough to do, and even if we ended up with several > arrays (like one for bufmgr locks) it wouldn't be too hard to write > code to figure out which array contains it and emit the appropriate > string. The only real problem that I see with this is that it might > cause a performance hit. A performance hit when running with > trace_lwlocks or LWLOCK_STATS is not really a problem, but people > won't like if --enable-dtrace slow things up. This seems like an interesting idea- but this and my other thought (having a defined array of strings) seem like they might fall over in the face of DSMs. > Preferences, other ideas? My preference would generally be "use more memory rather than CPU time"; so I'd vote for adding identifying info rather than having the code hunt through arrays to try and find it. > None of these ideas are a complete solution for LWLOCK_STATS. In the > other three cases noted above, we only need an identifier for the lock > "instantaneously", so that we can pass it off to the logger or dtrace > or whatever. But LWLOCK_STATS wants to hold on to data about the > locks that were visited until the end of the session, and it does that > using an array that is *indexed* by lwlockid. I guess we could > replace that with a hash table. Ugh. Any suggestions? Yeah, that's not fun. No good suggestions here offhand. Thanks, Stephen
Description: Digital signature