Re: Resource Owner reassign Locks
От | Heikki Linnakangas |
---|---|
Тема | Re: Resource Owner reassign Locks |
Дата | |
Msg-id | 4FE31440.8040909@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Resource Owner reassign Locks (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Resource Owner reassign Locks
Re: Resource Owner reassign Locks |
Список | pgsql-hackers |
On 18.06.2012 13:59, Heikki Linnakangas wrote: > On 10.06.2012 23:39, Jeff Janes wrote: > I found the interface between resowner.c and lock.c a bit confusing. > resowner.c would sometimes call LockReassignCurrentOwner() to reassign > all the locks, and sometimes it would call LockReassignCurrentOwner() on > each individual lock, with the net effect that's the same as calling > LockReleaseCurrentOwner(). And it doesn't seem right for > ResourceOwnerRemember/ForgetLock to have to accept a NULL owner. > > I rearranged that so that there's just a single > LockReassignCurrentOwner() function, like before this patch. But it > takes as an optional argument a list of locks held by the current > resource owner. If the caller knows it, it can pass them to make the > call faster, but if it doesn't it can just pass NULL and the function > will traverse the hash table the old-fashioned way. I think that's a > better API. > > Please take a look to see if I broke something. I hear no complaints, so committed. Thanks! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: