Re: Hot Standy introduced problem with query cancel behavior - Mailing list pgsql-hackers

From Joachim Wieland
Subject Re: Hot Standy introduced problem with query cancel behavior
Date
Msg-id dc7b844e0912300305u72a0dfe5sd5b37224be5c01d7@mail.gmail.com
Whole thread Raw
In response to Re: Hot Standy introduced problem with query cancel behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Hot Standy introduced problem with query cancel behavior  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Tue, Dec 29, 2009 at 4:22 PM, Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: "Tarun Sharma"
Date:
Subject: Re: Can we hide data from the superadmin
Next
From: Simon Riggs
Date:
Subject: Re: Cancelling idle in transaction state