| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
| Cc: | Daniel Farina <daniel(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_cancel_backend by non-superuser |
| Date: | 2011-10-02 10:55:51 |
| Message-ID: | CA+Tgmobfnf=4ytaQcR6=yeXkqB_rjcjA=MvwLmehKKrPF_6Qeg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Oct 1, 2011 at 10:11 PM, Euler Taveira de Oliveira
<euler(at)timbira(dot)com> wrote:
> On 01-10-2011 17:44, Daniel Farina wrote:
>>
>> 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.
>>
> I see. What about passing this decision to DBA? I mean a GUC
> can_cancel_session = user, dbowner (default is '' -- only superuser). You
> can select one or both options. This GUC can only be changed by superuser.
Or how about making it a grantable database-level privilege?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Torello Querci | 2011-10-02 10:58:12 | Re: pg_cancel_backend by non-superuser |
| Previous Message | Florian Pflug | 2011-10-02 09:32:29 | Re: Range Types - typo + NULL string constructor |