Daniel Farina <daniel@heroku.com> writes:
> On Mon, Mar 26, 2012 at 1:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not. I still wouldn't trust SIGTERMing an individual backend in a
>> production database.
> Okay, it was my precise intention to hand this to users so that not
> only could they cancel their queries, but also force the transaction
> to be aborted and the connection to be closed in case there is a
> client run amok. Is there a good injection site -- perhaps
> immediately after query cancellation -- where we can put in a
> rollback-and-disconnect behavior?
> Given this information, my understanding is that even the superuser is
> coerced into undertaking an action that is unnecessarily dangerous if
> they think the backend would respond to cancellation, but they also
> wish to close the connection.
Hrm, I think we're talking at cross-purposes here.
Me: "This mechanism hasn't been tested enough, and may still have nasty bugs."
You: "Then let's invent some entirely new mechanism."
I'm not seeing how that responds to the concern.
The original rationale for exposing pg_terminate_backend as a
superuser-only function was, as Magnus said, to take a baby step toward
providing the functionality generally. At this point we can either
think of another baby step, or cross our fingers and open the
floodgates. I'm just expressing discomfort with the second option.
I have to admit that I don't have a concrete proposal for a second baby
step (IOW an intermediate level of functionality that might provide
scope for more testing while not opening it up all the way yet).
regards, tom lane
