Skip site navigation (1) Skip section navigation (2)

Re: Transaction-scope advisory locks

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transaction-scope advisory locks
Date: 2011-02-01 14:00:03
Message-ID: AANLkTikk-Nz_euUi3X1gH5MyuAdJsehp=kG_E1ZDqCRS@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Feb 1, 2011 at 7:28 AM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja
> <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> wrote:
>> I still didn't address
>> the issue with pg_advisory_unlock_all() releasing transaction scoped locks,
>
> I guess you don't want independent locks, right? If an user object
> is locked by session locks, it also blocks backends trying to lock it
> with transaction locks.
>
> If so, I think an ideal behavior is below:
> - The transaction-or-session property is overwritten by the last lock
>  function call. We can promote session locks from/to transaction locks.

No.  The lock manager already supports session-locks.  This patch
should be worried about making sure that LockAcquire() gets called
with the flags the user wants, NOT with redefining the interaction
between transaction locks and session locks.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-02-01 14:03:27
Subject: Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Previous:From: Magnus HaganderDate: 2011-02-01 12:30:00
Subject: Re: setlocale and gettext in Postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group