Re: reducing the overhead of frequent table locks, v3

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.