On Tue, Feb 1, 2011 at 7:28 AM, Itagaki Takahiro <itagaki.takah...@gmail.com> wrote: > On Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja > <marko.tiikk...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
