| From: | Daniel Farina <daniel(at)heroku(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_cancel_backend by non-superuser |
| Date: | 2011-10-01 20:44:50 |
| Message-ID: | CAAZKuFYWk+5OD+g68LtSEZ1tmMG=Cr8-pXRpMA+G1XhzD8ydng@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 30, 2011 at 9:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> ISTM it would be reasonably non-controversial to allow users to issue
> pg_cancel_backend against other sessions logged in as the same userID.
> The question is whether to go further than that, and if so how much.
In *every* case -- and there are many -- where we've had people
express pain, this would have sufficed. Usually the problem is a
large index creation gone awry, or an automated backup process
blocking a schema change that has taken half the locks it needs, or
something like that -- all by the same role that is under control of
the folks feeling distress. If this minimal set is uncontroversial, I
would like to see that much committed and then spend some time
hand-wringing on whether to extend it.
If one does want to extend it, I think role inheritance makes the most
sense: a child role should be able to cancel its parent role's
queries, and not vice-versa. Since one can use SET ROLE in this case
anyway to basically act on behalf on that role, I think that, too,
should be uncontroversial.
--
fdr
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2011-10-01 21:08:02 | pg_dump issues |
| Previous Message | Jim Nasby | 2011-10-01 19:20:49 | Re: Single pass vacuum - take 2 |