From: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | pg_signal_backend() asymmetry |
Date: | 2012-06-28 00:38:24 |
Message-ID: | CAK3UJRHM_Foh09MAoFU4WEJOCCoL61JndNgUL+S0Q_Xer5sd=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
pg_signal_backend_asymmetry.diff | application/octet-stream | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Shigeru HANADA | 2012-06-28 01:57:31 | Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink |
Previous Message | Peter Geoghegan | 2012-06-28 00:15:56 | Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) |