Re: Exclusive lock for database rename

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.

In response to

Browse pgsql-hackers by date

  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