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

From Simon Riggs
Subject Re: Hot Standy introduced problem with query cancel behavior
Date
Msg-id 1262173288.19367.5027.camel@ebony
Whole thread Raw
In response to Re: Hot Standy introduced problem with query cancel behavior  (Joachim Wieland <joe@mcknight.de>)
List pgsql-hackers
On Wed, 2009-12-30 at 12:05 +0100, Joachim Wieland wrote:
> 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...)

Andres mentioned this in relation to Startup process sending signals to
backends. Startup needs to in-some cases issue a FATAL error also, which
is a separate issue from the discusion around SIGINT.

I will rework the FATAL case and continue to support you in finding a
solution to the cancel-while-idle case.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Cancelling idle in transaction state
Next
From: Simon Riggs
Date:
Subject: Re: Cancelling idle in transaction state