Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Function to kill backend

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>,"PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Function to kill backend
Date: 2004-07-25 18:03:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches

-----Original Message-----
From: pgsql-patches-owner(at)postgresql(dot)org on behalf of Magnus Hagander
Sent: Sun 7/25/2004 12:07 PM
To: Tom Lane; Bruce Momjian
Cc: Josh Berkus; PostgreSQL-patches
Subject: Re: [PATCHES] [HACKERS] Function to kill backend 
> >much further.  I recall being voted down though ...

> That's not quite the argument I think I had :-) But withuot being able
> to kill the backends, there just no way for me to handle the sitaution
> when I have a hundred clients eating up all available connections and/or
> memory, just sitting idle, because of some freak bug in a client. 

The first time I used it was for precisely this reason - some buggy PHP code opened hundreds of connections to a dev server which then remained open doing nothing except wasting resources. It was particularly useful in that case as I didn't have access to the web server at the time.

Shortly afterwards I added support to pgAdmin's server status tool which has proven quite handy (although I will admit, mainly for canceling ather than terminating).

I don't know the details of how it works, but is it any worse/better than 'kill -9' (which iirc is no longer considered an absolute no-no)?

Regards, Dave


pgsql-patches by date

Next:From: Andreas PflugDate: 2004-07-25 20:23:36
Subject: Re: [HACKERS] Function to kill backend
Previous:From: Magnus HaganderDate: 2004-07-25 17:34:36
Subject: Re: [HACKERS] Function to kill backend

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group