On Thu, Jun 21, 2012 at 5:32 AM, Heikki Linnakangas < heikki.linnakan...@enterprisedb.com> wrote:
> 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! I'd like to advocate for back-patching this to 9.0, 9.1, and 9.2. It has run without problems for a while now, and it can be considered a bug that systems with a very large number of objects cannot be upgraded in a reasonable time. There are possible ways to make the upgrade smoother by changing the new systems pg_upgrade rather the old systems server, but those methods will not be simpler, and not be as well tested. I'll add this proposal to the commit fest. Thanks, Jeff
