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 [EMAIL PROTECTED]
If simplicity worked, the world would be overrun with insects.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
