Robert Haas wrote: > Now, whether or not this facility is well designed is a worthwhile > question. Trace_lock_oidmin seems pretty sketchy to me, especially > because it's blindly applied to even to lock tags where the second > field isn't a relation - i.e. SET_LOCKTAG_TRANSACTION sets it to zero, > SET_LOCKTAG_VIRTUALTRANSACTION sets it to the localTransactionId, > SET_LOCKTAG_OBJECT sets it to the classId member of the objectaddress, > and advisory locks set it to 32 bits of the user's chosen locktag. So > by default, with trace_userlocks turned on and no other changes, > pg_advisory_lock(16384,0) produces output like that shown above and > pg_advisory_lock(16383,0) is met with silence. So maybe we should > just rip some or all of this stuff out instead of worrying too much > about it.
Please rip out whatever I missed. Thanks. The user locks were the old lock type before we had advisor locks, as far as I remember. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
