| From: | Joachim Wieland <joe(at)mcknight(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Kris Jurka <books(at)ejurka(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Hot Standy introduced problem with query cancel behavior |
| Date: | 2009-12-30 11:05:18 |
| Message-ID: | dc7b844e0912300305u72a0dfe5sd5b37224be5c01d7@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Dec 29, 2009 at 4:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> This seems like a fairly bad idea. One of the intended use-cases is to
> be able to manually "kill -INT" a misbehaving backend. Assuming that
> there will be valid info about the signal in shared memory will break
> that.
I never intended to change the current behavior.
Actually I wanted to even enhance it by allowing to also cancel an idle
transaction via SIGINT. We are free to define what should happen if there is no
internal reason available because the signal has been sent manually.
We can also use SIGUSR1 of course but then you cannot cancel an idle
transaction just from the commandline. Not sure if this is necessary
though but I would have liked it in the past already (I once used a version of
slony that left transactions idle from time to time...)
Joachim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2009-12-30 11:37:20 | Re: Cancelling idle in transaction state |
| Previous Message | Tarun Sharma | 2009-12-30 10:45:25 | Re: Can we hide data from the superadmin |