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 21:08:41
Message-ID: 15040.1336079321@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 3:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm inclined to say that you can PREPARE if your session holds a given
>> advisory lock at either session or transaction level, but not both.
>> This is a bit annoying but doesn't seem likely to be a real problem in
>> practice, so thinking of a hack to support the case seems like more
>> work than is justified.

> I'd be more inclined to say that if you have a session-level lock, you
> can't prepare, period.

The bug report that started this investigation was precisely that
preparing in the presence of a session-level lock failed, where it has
worked in every release before 9.1; the prepare is supposed to simply
ignore session locks.

> Doesn't a rollback release session-level locks?

No, it doesn't. Read
http://www.postgresql.org/docs/devel/static/explicit-locking.html#ADVISORY-LOCKS
(which could use some wordsmithing, but the specification is clear
enough)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-03 21:18:39 Re: Advisory locks seem rather broken
Previous Message Daniel Farina 2012-05-03 21:04:03 Re: CLOG extension