Re: Patch to allow users to kill their own queries - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Patch to allow users to kill their own queries
Date
Msg-id CABUevEz3EbYLcY4p_+vgyzhzEGECd9TcC4P6YTwJieqMugvhgA@mail.gmail.com
Whole thread Raw
In response to Re: Patch to allow users to kill their own queries  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: Patch to allow users to kill their own queries  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Mon, Dec 19, 2011 at 15:50, Greg Smith <greg@2ndquadrant.com> wrote:
> 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.

How about something like this - passing it in as a parameter?

That said - can someone who knows the translation stuff better than me
comment on if this is actually going to be translatable, or if it
violates too many translation rules?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Attachment

pgsql-hackers by date:

Previous
From: Euler Taveira de Oliveira
Date:
Subject: Re: xlog location arithmetic
Next
From: Robert Haas
Date:
Subject: Re: Review: Non-inheritable check constraints