Re: Transaction-scope advisory locks - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: Transaction-scope advisory locks
Date
Msg-id AANLkTi=EerOrjHWJmeiFpBinbRBZ0pHDXX344raSSdAV@mail.gmail.com
Whole thread Raw
In response to Re: Transaction-scope advisory locks  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Responses Re: Transaction-scope advisory locks  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
List pgsql-hackers
On Thu, Feb 10, 2011 at 08:36, Marko Tiikkaja
<marko.tiikkaja@cs.helsinki.fi> wrote:
>> One issue might be in pg_locks
> Robert suggested not doing this for 9.1, and I don't have anything against
> that.

Agreed.

> Updated patch attached.

Looks good to commit. I note a few minor issues for committer:

* Functions listed in "Table 9-62. Advisory Lock Functions" might need sorted in alphabetical order.

* We could extend LockReleaseAll() to have the 3rd mode instead of LockReleaseSession().  Existing behavior is:
| LockReleaseAll(LOCKMETHODID lockmethodid, bool allLocks)
|   allLocks == true: release all locks including session locks.
|   allLocks == false: release all non-session locks.

* Or, we might have one subroutine for LockReleaseSession() and LockReleaseCurrentOwner(). They have similar codes.

-- 
Itagaki Takahiro


pgsql-hackers by date:

Previous
From: Radosław Smogura
Date:
Subject: Re: Varchar and binary protocol
Next
From: Merlin Moncure
Date:
Subject: Re: Varchar and binary protocol