On Sat, 24 Jan 2004, Lee Harr wrote:
> >>Every once in a while my automated script fails because
> >>some other system which should have disconnected
> >>failed to unhook. The old data and old connection are
> >>not important to me. The new run needs to go through.
> >
> >You can look for people connected and kick them out with kill -2 on
> >their pid. The trick is to start your own script (which probably
> >isn't "failing" exactly, but blocking, right?), and then (since
> >you've locked the relevant objects that way, such that nobody else
> >can get in) use the shell to kill -2 other connections. Evil and
> >possibly dangerous, but you said you didn't care about the old data.
> >
>
>
> Yea, grepping through the output from ps and killing the other
> backend process was my first thought. The only problem is
> that the user that owns the database (and runs the automatic
> report script) is not necessarily the one that is causing the
> problem. So that means somehow I need to kick off another
> script with elevated priveleges to take care of it ...
>
> I would rather not have to do that, but I do not see another way.
If you are creating a database from scratch why not create a brand new
database and drop the old one at some later point in time when no one is
connected. This has the additional benefit of the old db being available
while the new one is being built.
Kris Jurka
