Re: LOCK_DEBUG is busted

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. +