Re: Advisory locks seem rather broken

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Subject: Re: Advisory locks seem rather broken
Date: 2012-05-03 17:28:43
Message-ID: 28004.1336066123@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, May 3, 2012 at 12:12 PM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-05-03 17:36:16 Re: "unexpected EOF" messages
Previous Message Simon Riggs 2012-05-03 17:27:44 Re: CLOG extension