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
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 |