On Wed, Feb 9, 2011 at 7:12 AM, Itagaki Takahiro <itagaki.takah...@gmail.com> wrote: > One issue might be in pg_locks, as you pointed out in the previous mail: >> if a session holds both a transaction level and a session level lock >> on the same resource, only one of them will appear in pg_locks. > Also, we cannot distinguish transaction-level locks from session-level > locks from pg_locks. > > It was not an issue before because session locks are only used in > internal implementation. It looks as a transaction from users. > However, this feature reveals the status in public. We might need > to add some bits to shared lock state to show which lock is session-level.
Presumably that would carry a small performance penalty, since changing the status of the lock would require modifications to the shared hash table, not just the backend-private one. It may still be worth doing, but I'm inclined to think that it's a separate patch that someone could submit for 9.2. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
