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: (view raw, whole thread or download thread mbox)
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
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-2018 The PostgreSQL Global Development Group