Re: Transaction-scope advisory locks
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Itagaki Takahiro <itagaki.takahiro@gmail.com>
Cc: Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>, pgsql-hackers@postgresql.org
Date: 2011-02-01T14:00:03Z
Lists: pgsql-hackers
On Tue, Feb 1, 2011 at 7:28 AM, Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote: > On Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja > <marko.tiikkaja@cs.helsinki.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