On Tue, Feb 1, 2011 at 7:28 AM, Itagaki Takahiro <[email protected]> wrote: > On Fri, Jan 28, 2011 at 17:12, Marko Tiikkaja > <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
