Re: Exclusive lock for database rename
От | Martijn van Oosterhout |
---|---|
Тема | Re: Exclusive lock for database rename |
Дата | |
Msg-id | 20051109084143.GA21585@svana.org обсуждение исходный текст |
Ответ на | Re: Exclusive lock for database rename (daveg <daveg@sonic.net>) |
Ответы |
Re: Exclusive lock for database rename
How postgres find OID of function from opclassoid |
Список | pgsql-hackers |
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. Anyway, this is theoretical as the code for this doesn't exist. It was just an idea. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
В списке pgsql-hackers по дате отправления: