On Sun, Jun 12, 2011 at 03:57:08PM -0400, Robert Haas wrote: > Thus far, locks taken via the fast-path mechanism are not shown in > pg_locks. I've been mulling over what to do about that. It's a bit > tricky to show a snapshot of the locks in a way that's guaranteed to > be globally consistent, because you'd need to seize one lock per > backend plus one lock per lock manager partition, which will typically > exceed the maximum number of LWLocks that can be simultaneously held > by a single backend. And if you don't do that, then you must either > scan the per-backend queues first and then the lock manager > partitions, or the other way around. Since locks can bounce from the > per-backend queues to the primary lock table, the first offers the > possibility of seeing the same lock twice, while the second offers the > possibility of missing it altogether. I'm inclined to scan the > per-backend queues first and just document that in rare cases you may > see duplicate entries. We could also de-duplicate before returning > results but I doubt it's worth the trouble. Anyway, opinions?
Possibly returning duplicates seems okay. > A related question is whether a fast-path lock should be displayed > differently in pg_locks than one which lives in the primary lock > table. We could add a new boolean (or "char") column to pg_locks to > mark locks as fast-path or not, or maybe change the granted column to > a three-valued column (fast-path-granted, normal-granted, waiting). > Or we could omit to distinguish. Again, opinions? An extra boolean for that sounds good. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
