From: | daveg <daveg(at)sonic(dot)net> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Jochem van Dieten <jochemd(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Exclusive lock for database rename |
Date: | 2005-11-09 08:50:18 |
Message-ID: | 20051109085018.GG20692@sonic.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sonic(dot)net
If simplicity worked, the world would be overrun with insects.
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2005-11-09 09:47:30 | Re: compiling on windows with mingw |
Previous Message | Martijn van Oosterhout | 2005-11-09 08:41:49 | Re: Exclusive lock for database rename |