Re: Change pg_cancel_*() to ignore current backend

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, "david(dot)g(dot)johnston(at)gmail(dot)com >> David G Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Subject: Re: Change pg_cancel_*() to ignore current backend
Date: 2015-05-22 18:45:15
Message-ID: CAFj8pRBi-8keJX4FKddUxnd9Z05cOWZ6ZDtiw0C0LzM+ezGgvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-05-22 20:28 GMT+02:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 5/21/15 7:12 AM, Robert Haas wrote:
>
>> On Wed, May 20, 2015 at 8:46 PM, Andres Freund <andres(at)anarazel(dot)de>
>> wrote:
>>
>>> I've a hard time believing it's actually a good idea to change this. It
>>> pretty much seems to only be useful if you're doing unqualified SELECT
>>> pg_cancel_backend(pid) FROM pg_stat_activity; type queries. I don't see
>>> that as something we need to address.
>>>
>>
>> +1. I'm not saying this isn't annoying - I've been annoyed by it
>> myself - but IMHO it's really not worth having two functions that do
>> 99% the same thing. Then, instead of having to remember to exclude
>> your own backend using the same SQL syntax you use for everything
>> else, you have to remember which of two similarly-named functions to
>> call if you don't want to kill your own backend. That might be better
>> for some people, but it won't be better for everyone.
>>
>
> OTOH, if we allowed RAISE FATAL in plpgsql there'd be no need for
> self-termination via pg_terminate_backend(). I also don't see a problem
> with allowing self-termination, with the default being to disallow it.
>
> I suspect the number of people writing code that need self-termination is
> very, very small, whereas probably every DBA out there has been bitten by
> this. This is the type of thing that gives Postgres a reputation for being
> 'hard to use'. I would think the benefit of the larger group would outweigh
> the pain the smaller group would feel changing their code, but of course
> that's just my opinion and I don't see any easy way to quantify that.
>
> You and Andreas think it's fine as-is.
> Tom and Jon Nelson maybe don't like it as-is, but won't break backwards
> compatibility.
>

I am with Tom and Jon - I don't see a good enough reason why to change long
used behave without more users reports. Possibility to kill self is simple
test, so this feature is working.

Regards

Pavel

> David Steele and I seem fine with breaking compat., not sure about
> Fabrizio.
>
> Given the opposition unless some others speak up I'll just drop it.
> --
> Jim Nasby, Data Architect, Blue Treble Consulting
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-05-22 18:59:18 Re: jsonb concatenate operator's semantics seem questionable
Previous Message Jim Nasby 2015-05-22 18:38:47 Re: jsonb concatenate operator's semantics seem questionable