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

Re: [HACKERS] Function to kill backend

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>,Magnus Hagander <mha(at)sollentuna(dot)net>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,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-26 14:02:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:

> If you don't mind plastering a "use at your own risk" sign on it, then
> go for it.

killing a backend is obviously much more "at your own risk" than a 
descent function.

Taken from your mail, I understand that a killed backend might leave 
some loose ends, eg. open locks, which would degrade the cluster's 
performance. Still, it should not corrupt the shared mem, just leave it 
as if the backend's still alive and sleeping, right?

You'd kill a backend only if your complete cluster is suffering from it, 
and you hope to keep it running by just shooting that process. If the 
cluster still has that uncleaned locks or so, you're unlucky and need to 
shutdown the cluster.

Maybe we should supply a restricted version of pg_terminate_backend 
that's callable from admin interfaces only so we can make sure that the 
user was warned what he's doing before the termination is executed, 
something like that:

ticket := select pg_admin_ticket();
/* calculate well-known stuff on ticket
    and issue before it times out */
select pg_terminate_backend(ticket_hash);


In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2004-07-26 14:21:19
Subject: Re: [HACKERS] Function to kill backend
Previous:From: Andrew DunstanDate: 2004-07-26 13:41:09
Subject: Re: pg_config

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