On Wed, 2005-05-11 at 17:49, Chris Browne wrote:
> smarlowe@g2switchworks.com (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'.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly