Re: Patch to allow users to kill their own queries
От | Magnus Hagander |
---|---|
Тема | Re: Patch to allow users to kill their own queries |
Дата | |
Msg-id | CABUevEz3EbYLcY4p_+vgyzhzEGECd9TcC4P6YTwJieqMugvhgA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch to allow users to kill their own queries (Greg Smith <greg@2ndQuadrant.com>) |
Ответы |
Re: Patch to allow users to kill their own queries
|
Список | 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/
Вложения
В списке pgsql-hackers по дате отправления: