Re: Change pg_cancel_*() to ignore current backend

Поиск
Список
Период
Сортировка
От Fabrízio de Royes Mello
Тема Re: Change pg_cancel_*() to ignore current backend
Дата
Msg-id CAFcNs+pmna0FpOzdV1itZ+PXdbmxaU7CMa42JZnnJAD=Mq=hSQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Change pg_cancel_*() to ignore current backend  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Change pg_cancel_*() to ignore current backend  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers


Em terça-feira, 19 de maio de 2015, Jim Nasby <Jim.Nasby@bluetreble.com> escreveu:
On 5/19/15 6:30 PM, David G. Johnston wrote:
On Tue, May 19, 2015 at 4:23 PM, Marko Tiikkaja <marko@joh.to
<mailto:marko@joh.to>>wrote:

    On 2015-05-20 00:59, Jim Nasby wrote:

        I find it annoying to have to specifically exclude
        pg_backend_pid() from
        pg_stat_activity if I'm trying to kill a bunch of backends at
        once, and
        I can't think of any reason why you'd ever want to call a
        pg_cancel_*
        function with your own PID.


    That's a rather easy way of testing that you're handling FATAL
    errors correctly from a driver/whatever.


I'm having trouble thinking of a PC name for the function we create that
should do this; while changing the pg_cancel_* functions to operate more
safely.

We could add a second parameter to the current functions: allow_own_pid DEFAULT false. To me that seems better than an entirely separate set of functions.


+1 to add a second parameter to current functions.




--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Back-branch update releases planned for next week