pg_signal_backend() asymmetry

Поиск
Список
Период
Сортировка
От Josh Kupershmidt
Тема pg_signal_backend() asymmetry
Дата
Msg-id CAK3UJRHM_Foh09MAoFU4WEJOCCoL61JndNgUL+S0Q_Xer5sd=w@mail.gmail.com
обсуждение исходный текст
Ответы Re: pg_signal_backend() asymmetry  (Daniel Farina <daniel@heroku.com>)
Список pgsql-hackers
Hi all,

I have one nitpick related to the recent changes for
pg_cancel_backend() and pg_terminate_backend(). If you use these
functions as an unprivileged user, and try to signal a nonexistent
PID, you get:

  ERROR:  must be superuser or have the same role to cancel queries
running in other server processes

Whereas if you do the same thing as a superuser, you get:

  WARNING:  PID 123 is not a PostgreSQL server process
   pg_cancel_backend
  -------------------
   f
  (1 row)

The comment above the WARNING generated for the latter case says:

                /*
                 * This is just a warning so a loop-through-resultset
will not abort
                 * if one backend terminated on its own during the run
                 */

which is nice, but wouldn't unprivileged users want the same behavior?
Not to mention, the ERROR above is misleading, as it claims the
nonexistent PID really belongs to another user.

A simple fix is attached. The existing code called both
BackendPidGetProc(pid) and IsBackendPid(pid) while checking a
non-superuser's permissions, which really means two separate calls to
BackendPidGetProc(pid). I simplified that to down to a single
BackendPidGetProc(pid) call.

Josh

Вложения

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Следующее
От: Shigeru HANADA
Дата:
Сообщение: Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink