Re: Change pg_cancel_*() to ignore current backend

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Change pg_cancel_*() to ignore current backend
Дата
Msg-id 555C1E38.9020905@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Change pg_cancel_*() to ignore current backend  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Ответы Re: Change pg_cancel_*() to ignore current backend  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Re: Change pg_cancel_*() to ignore current backend  (David Steele <david@pgmasters.net>)
Re: Change pg_cancel_*() to ignore current backend  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 5/19/15 9:19 PM, Fabrízio de Royes Mello wrote:
>     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.

Instead of allow_own_pid, I went with skip_own_pid. I have the function
still returning true even when it skips it's own PID... that seems a bit
weird, but I think it's better than returning false. Unless someone
thinks it should return NULL, but I don't see that as any better either.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

Вложения

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

Предыдущее
От: Chris Rogers
Дата:
Сообщение: Re: CTE optimization fence on the todo list?
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: jsonb concatenate operator's semantics seem questionable