It's sad, really. You're about to move a database to archival storage, possibly to /dev/null, but pesky users keep talking to it.
So you try
DROP DATABASE foo;
but you get
ERROR: database "foo" is being accessed by other users
DETAIL: There are 2 other session(s) using the database.
Next, you try killing off all the connections to foo, but those pesky users just keep re-connecting! What's to do? Here's what in modern PostgreSQL idiom:
UPDATE pg_catalog.pg_database SET datallowconn=false WHERE datname='foo';
SELECT pg_catalog.pg_terminate_backend(pid)
FROM pg_catalog.pg_stat_activity WHERE datname='foo';
DROP DATABASE foo;
and here's for 9.1 or worse.
UPDATE pg_catalog.pg_database SET datallowconn=false WHERE datname='foo';
SELECT pg_catalog.pg_terminate_backend(procpid)
FROM pg_catalog.pg_stat_activity WHERE datname='foo';
DROP DATABASE foo;
All gone!
As of PostgreSQL 13, you can do this much more simply via
DROP DATABASE foo FORCE;
UPDATE pg_catalog.pg_database SET datallowconn=false WEHRE datname='foo';
As an alternative, though not nearly as elegant, you could configure pg_hba.conf to deny access to said database and reload Postgres.
Re: doing it via pg_hba.conf, the original issue came up in a situation where "Make it work without shell access" was a mandate. I thought what I came up with to meet that requirement was kinda cute, so I published it
kill `ps -ef | grep MYDB | grep -v grep | awk '{print $2}'`