Re: Patch to allow users to kill their own queries

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to allow users to kill their own queries
Date: 2011-12-19 14:50:26
Message-ID: 4EEF4F32.6030402@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/18/2011 07:31 AM, Magnus Hagander wrote:
> * I restructured the if statements, because I had a hard time
> following the comments around that ;) I find this one easier - but I'm
> happy to change back if you think your version was more readable.

That looks fine. I highlighted this because I had a feeling there was
still some gain to be had here, just didn't see it myself. This works.

> * The error message in pg_signal_backend breaks the abstraction,
> because it specifically talks about terminating the other backend -
> when it's not supposed to know about that in that function. I think we
> either need to get rid of the hint completely, or we need to find a
> way to issue it from the caller. Or pass it as a parameter. It's fine
> for now since we only have two signals, but we might have more in the
> future..

I feel that including a hint in the pg_terminate_backend case is a UI
requirement. If someone has made it as far as discovering that function
exists, tries calling it, and it fails, the friendly thing to do is
point them toward a direction that might work better. Little things
like that make a huge difference in how friendly the software appears to
its users; this is even more true in cases where version improvements
actually expand what can and cannot be done.

My quick and dirty side thinks that just documenting the potential
future issues would be enough:

"Due to the limited number of callers of this function, the hint message
here can be certain that pg_terminate_backend provides the only path to
reach this point. If more callers to pg_signal_backend appear, a more
generic hint mechanism might be needed here."

If you must have this more generic mechanism available, I would accept
re-factoring to provide it instead. What I wouldn't want to live with
is a commit of this where the hint goes away completely. It's taken a
long time chopping the specification to get this feature sorted out; we
might as well make what's left be the best it can be now.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-12-19 14:56:25 Re: review: CHECK FUNCTION statement
Previous Message Alvaro Herrera 2011-12-19 14:39:44 Re: Command Triggers