Tom Lane wrote:
> Sysadmin <linux@xxxxxxxxxxx> writes:
>> I'm finding that routinely when I try to reload a database on a server
>> where I know there are no connections to a given DB I get the error:
>
>> $ dropdb foo && createdb foo -O bar && psql foo -f /path/to/db.out
>> dropdb: database removal failed: ERROR: database "foo" is being
>> accessed by other users
>
> If it says there are other connections, then there really are other
> connections --- there are not any known bugs in that logic.
>
> What I am wondering though is whether you are allowing for the nonzero
> exit time of a backend process. If the above is part of a script that
> was just doing something in database foo, then the drop could fail
> because the backend that was serving that session is still cleaning up.
> The quickest solution is a 'sleep 1' (or so) before the dropdb.
>
> (FWIW, 8.3 will have some delay built in here to help mask this issue.)
>
> regards, tom lane
Thanks Tom,
In this case no, it's not part of a script. I was doing this manually
at the OS shell. This error has happened many times, and restarting the
postgres server always clears it and lets me continue.
Is there a way to tell Postgres to terminate any existing connections
to a given DB to avoid the need to restart the entire server?
Madi
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
