Re: Exclusive lock for database rename
От | daveg |
---|---|
Тема | Re: Exclusive lock for database rename |
Дата | |
Msg-id | 20051109085018.GG20692@sonic.net обсуждение исходный текст |
Ответ на | Re: Exclusive lock for database rename (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-hackers |
On Wed, Nov 09, 2005 at 09:41:49AM +0100, Martijn van Oosterhout wrote: > On Tue, Nov 08, 2005 at 04:06:32PM -0800, daveg wrote: > > I think this wait with an exponentially rising delay hurts not helps. If the > > stricter lock can be granted in a short time, ie the dalay could be small, > > then there is no problem. If the lock cannot be granted and the delay expires > > the stricter lock has incurred extra wait time already and allowed newer > > conflicting requests ahead of it possibly increasing the total wait time. > > As the timeout increases newer requests end up waiting for the new longer > > time anyway so the overall effect is to increase all lockers total wait time. > > But I don't see an alternative. Group A needs access to the resource, > Group B (the rename) needs exclusive access. If you don't start holding > off the members of group A, the rename will never complete. > > If you keep doing say 30 second waits, then any regular queries that > take longer than that can block you out forever. The only way to > eventually win is to eventually have a timeout longer than the longest > currently running query. Exactly. Timing out the waits won't work. -dg -- David Gould daveg@sonic.net If simplicity worked, the world would be overrun with insects.
В списке pgsql-hackers по дате отправления: