On Wed, 2005-05-11 at 17:49, Chris Browne wrote: > smarlowe@xxxxxxxxxxxxxxxxx (Scott Marlowe) writes: > > > On Wed, 2005-05-11 at 15:08, Ing. Jhon Carrillo wrote: > >> I have a problem with the users administration. When I want to erase > >> (drop) some databases there's an error: ** database "name_db" is being > >> accessed by other users.** I want to kill the user sessions conected > >> but i don't know how to do it (Kill the user sessions). > > > > First, use ps to find the pid of the offending users. for instance: > > > > ps ax|grep postgres|grep test > > 18925 pts/1 S 0:00 postgres: postgres test [local] idle > > > > then, as the postgres superuser, kill the backend: > > > > kill 18925 > > You may want to be careful about what signal you submit. > > If you do "kill -9", for instance, that may be a more severe > "thwacking" of the system than you intended. > > Hitting it with "kill -2" is usually the right answer; that's SIGINT. > > Other signals may cause the database to kill ALL the backends. > "kill -3", for instance... > > "kill -9" will terminate the whole database system, 'with extreme > prejudice,' which will be quite likely to turn out badly :-(. Not exactly. kill -9 on a single backend will not kill the whole database but WILL cause all backends to terminate and the database server to restart, which is rather severe. Also note that postgresql is designed to survive a kill -9 on all signals with aplomb, but a production system is definitely not the place to be testing it, eh? :) Also note that while most signal numbers are the same, it's a good idea to use the text name assigned, as they are always pretty much the same across different systems. Without specifying a specific signal, a TERM should be sent, which is a 15 on both Solaris and Linux and (I think) BSD. So, 'kill -s sigterm pidhere' is pretty much the same as 'kill pidhere'.
