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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +