On 05/21/2008 11:32 PM, Greg Sabino Mullane wrote:
Unfortunately, the disconnect call apparently doesn't really disconnect,
because the dropdb command fails with an error that other users are
still connected to the database.
This works fine for me. It's most likely that you have other clients still
attached to the database. Try seeing who's connected by doing a:
SELECT * FROM pg_stat_activity;
No, there were no other clients connected.
When I look in pg_stat_activity, I see a row with a valid procpid (i.e.,
it refers to a running postgres process), a blank client_addr, and a
client_port value of -1. It appears that the postgres process continues
to run for a little while after the client disconnects from it, and that
one cannot drop the database until this process exits. So it's just a
matter of waiting a little while after the disconnect before trying to
do the dropdb command.
Note that I'm not actually convinced the stale row in pg_stat_activity
was the one from DBI. In fact, I think it was probably from another
external command I ran on the database. So I suspect that in fact, DBI
is closing its connection properly, and it's that other command that's
not closing it properly and thus causing the process to hang around a
little while before exiting. That's just a guess, though.
In any case, thanks for the response.
Jonathan Kamens
