Re: Change pg_cancel_*() to ignore current backend

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Change pg_cancel_*() to ignore current backend
Дата
Msg-id CAFj8pRBi-8keJX4FKddUxnd9Z05cOWZ6ZDtiw0C0LzM+ezGgvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Change pg_cancel_*() to ignore current backend  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers


2015-05-22 20:28 GMT+02:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 5/21/15 7:12 AM, Robert Haas wrote:
On Wed, May 20, 2015 at 8:46 PM, Andres Freund <andres@anarazel.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: jsonb concatenate operator's semantics seem questionable
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: jsonb concatenate operator's semantics seem questionable