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

Re: Is there a way to kill a connection from the pg_stat_activitly list?

From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: "Jessica Richard" <rjessil(at)yahoo(dot)com>
Cc: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "Tommy Gildseth" <tommy(dot)gildseth(at)usit(dot)uio(dot)no>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Is there a way to kill a connection from the pg_stat_activitly list?
Date: 2007-10-16 13:05:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On 10/16/07, Jessica Richard <rjessil(at)yahoo(dot)com> wrote:
> select pg_cancel_backend(procpid) solved half of my least it
> terminated the query for that user... but it is still holding a user
> connection in IDLE state....If I have too many of those, Postgres may run of
> out of user connections....
> I already knew how to kill a connection if the connection is from the local
> host. But I have many remote connections coming from different machines...
> hard to kill with unix command "kill"...  One time, I was testing to kill a
> particular connection on a testing machine, the entrie Postgres was brought
> down....

That's why I said to write a C stored procedure to do it and install
it on the server.  That way you could call it the same way as

> I need to find a safer, cleaner way to disconnect a user from Postgres when
> needed.

At this point in time, there isn't one.

Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation                | fax: 732.331.1301
499 Thornall Street, 2nd Floor          | jonah(dot)harris(at)enterprisedb(dot)com
Edison, NJ 08837                        |

In response to


pgsql-admin by date

Next:From: Tom LaneDate: 2007-10-16 16:50:15
Subject: Re: when inserting to table, text type parameter become NULL (after big assignment to this parameter)
Previous:From: Greg CaultonDate: 2007-10-16 12:55:30
Subject: installation automation

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