Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, May 3, 2012 at 12:12 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> AFAICS you'd either use transactional or session level, but to use
>> both seems bizarre.
> I'm a bit confused by all this, because we use both transaction and
> session level locks internally - on the same lock tags - so I don't
> know why we think it wouldn't be useful for user code to do the same.
Yeah. I'm too lazy to go look up the original discussion for the
feature, but it seems to me that having session-lifetime and
transaction-lifetime advisory locks conflict is exactly what was wanted.
If you want some that don't conflict, just choose distinct key values.
> In fact I'm a bit confused by the original complaint for the same
> reason - if LockRelationOid and LockRelationIdForSession can coexist,
> why doesn't the same thing work for advisory locks?
The problem (or problems) is bad implementation, not the specification.
In particular, at least one place that should have been patched was not.
regards, tom lane