Re: Patch to allow users to kill their own queries

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to allow users to kill their own queries
Date: 2011-12-20 13:30:08
Message-ID: CABUevEz3EbYLcY4p_+vgyzhzEGECd9TcC4P6YTwJieqMugvhgA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 19, 2011 at 15:50, Greg Smith <greg(at)2ndquadrant(dot)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 Content-Type Size
user_signal-v5.patch text/x-patch 5.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-20 13:32:49 Re: Review: Non-inheritable check constraints
Previous Message Euler Taveira de Oliveira 2011-12-20 13:08:50 Re: xlog location arithmetic