force drop of database others are accessing

[Lee Harr]

Is there any way to forcibly disconnect all users from a
database, or else force the drop of the database even
though others are still connected?

I have a report I run where I first drop the old report db
then create it anew, read in a recent dump file and then
run a bunch of queries to build up the reports.

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.

It seems like maybe using schema I could do this ... since
that does not remove the database, and I could drop ...
cascade to make sure everything goes, but all of my scripts
assume separate databases now, and they need to be
rethought and rewritten to work with schema.

Any ideas?

__________________________________________________ _______________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Andrew Sullivan]

On Sat, Jan 24, 2004 at 12:18:06AM +0000, 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.

A

--
Andrew Sullivan | aj*@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly