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: 41050F0F.40401@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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);

Regards,
Andreas

In response to

Responses

Browse pgsql-patches by date

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