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 по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Exclusive lock for database rename
Следующее
От: ITAGAKI Takahiro
Дата:
Сообщение: Optimization of the alignment padding