Re: Transaction-scope advisory locks
От | Robert Haas |
---|---|
Тема | Re: Transaction-scope advisory locks |
Дата | |
Msg-id | AANLkTikk-Nz_euUi3X1gH5MyuAdJsehp=kG_E1ZDqCRS@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Transaction-scope advisory locks (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: