Re: Function to kill backend

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <josh(at)agliodbs(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Function to kill backend
Date: 2004-04-04 12:19:21
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE34B687@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> Killing backends with runaway queries is a routine administrative
>> task.
>
>Cancelling runaway queries is a routine task. I'm less
>convinced that a
>remote kill (ie SIGTERM) facility is such a great idea.

Consider a scenario like:
User A starts transaction.
User A issues a LOCK TABLE (or does something to lock it)
User A goes on vacation without commit/rollback

User A might well be Program A instead, of course. Caught in a tight
loop, waiting for user input, or whatever.

In this case, SIGINT (query cancel) will not help, because all locks
held by the transaction will still be held.

If there was a way to "force rollback" a connection, that could be done.
Buf AFAIK there are none? And would those be safer/better than
terminating the backend?

//Magnus

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-04-04 17:27:44 Re: thread_test.c problems
Previous Message wespvp 2004-04-04 09:03:05 Re: thread_test.c problems