Re: pg_cancel_backend by non-superuser - Mailing list pgsql-hackers

From Torello Querci
Subject Re: pg_cancel_backend by non-superuser
Date
Msg-id CA+igE6SR5XMnGpW5Bwk6KkK1NY6eFhecev1w82iZpA_80wXq2Q@mail.gmail.com
Whole thread Raw
In response to Re: pg_cancel_backend by non-superuser  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
Hi Greg

2011/12/13 Greg Smith <greg@2ndquadrant.com>:
> On 12/11/2011 05:29 PM, Torello Querci wrote:
>>
>> I will try to adjust the patch and submit for the next Commit Fest if
>> this is ok for you.
>>
>
>
> I don't think we'll need this, it will take a bit to explain why though.
>
> First, thanks for returning this topic to discussion and keeping up with all
> the controversy around it.  You said back in February this was your first
> post here, and I doubt you expected that 10 months later this would still be
> active and argued over.  The fact that you're still here and everyone knows
> your name now is itself an accomplishment, many people just give up on their
> submission ideas under far less negative feedback.
>
Why. I need one feature, can spend some time to try to get it and I try.
This is only way to lean that I know.

> I just took a long look at all three of the submissions in this area we've
> gotten.  The central idea that made yours different was making the database
> owner the person allowed to cancel things.  That hadn't been suggested as a
> cancellation requisite before that I know of, and this code may wander in
> that direction one day.  It's just a bit too much to accept right now.  You
> seem to need that specific feature for your environment.  If that's the
> case, you might want to develop something that works that way, but handles
> the concerns raised here.  The fact that it's not acceptable for a database
> owner to cancel a superuser query is the biggest objection, there were some
> others too.  Ultimately it may take a reworking of database permissions to
> really make this acceptable, which is a larger job than I think you were
> trying to get involved with.
>
Probably you have right :(

> Unfortunately, when I look at the new spec we have now, I don't see anything
> from what you did that we can re-use.  It's too specific to the
> owner-oriented idea.  The two other patches that have been submitted both
> are closer to what we've decided we want now.  What I'm going to do here is
> mark your submission "returned with feedback".
>
Again no problem.
The only thing that I need (not only me obviusly) is give the
permission to one or more users
to kill session and query owned by other users.
Have a kind of ACL where is specify who can kill and which is the right way.

My problem is related to production environment where an application
server access the database server and I am the database owner, not the
DBA.
So I need to kill the application server sessions (again I not the
root of application server so I not able to stop and restart it).
I hope to explain my scenario if not before.

> Rather than wait for something new from you, I'm going to review and rework
> the other two submissions.  That I can start on right now.  It's taken so
> long to reach this point that I don't want to wait much longer for another
> submission here, certainly not until over a month from now when the next CF
> starts.  We need to get the arguments around a new version started earlier
> than that.  Thanks for offering to work on this more, and I hope there's
> been something about this long wandering discussion that's been helpful to
> you.  As I said, you did at least make a good first impression, and that is
> worth something when it comes to this group.
>
Thanks Greg.
I hope to meet you at Fosdem if you wil go there.


Best Regards, Torello


pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: JSON for PG 9.2
Next
From: Tom Lane
Date:
Subject: Re: review: CHECK FUNCTION statement