Oleg Bartunov <oleg@sai.msu.su> writes:
>> You cannot destroy a DB while there are backends connected to it;
>> all hell breaks loose if you do. See thread "How to destroy your entire
>> Postgres installation" in pg-hackers in late Sept. 1998.
> I did it without any problem :-)
You were lucky. I suffered severe database corruption in *other*
databases when I did it by accident last year.
>> The correct fix is to add an interlock that prevents "destroydb" when
>> there are connected backends. I don't know just how that might be done,
>> however.
> I'm not sure preventing "destroydb" is a good idea. Imagine some
> user connects to db (via psql) and hold it for a weekend.
If you cannot stop the connected backends first, you should not be able
to kill the database. I suppose a different way to look at it is that
destroydb should kill any backends connected to the database before it
does anything else. I'd suggest that that only happen with user
confirmation though, since destroying an active database seems to me
to be something you'd never really want to do.
> The problem would be worse in case of 24*7 life-cycle of Web-database
> connectivity if you decide "prevent destroydb" feature !
If you have an active website using a database, what are you doing
destroying the database? We're not talking about dropping a temp table
here... I find it hard to imagine what you'd use this "feature" for,
except for shooting yourself in the foot.
regards, tom lane