On Tue, Feb 1, 2011 at 7:28 AM, Itagaki Takahiro
> 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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 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 Hagander||Date: 2011-02-01 12:30:00|
|Subject: Re: setlocale and gettext in Postgres|