<p>I like this idea<p>+1<div class="gmail_quote">Il giorno 02/ott/2011 12:56, "Robert Haas" <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>ha scritto:<br type="attribution" />> On Sat, Oct
1,2011 at 10:11 PM, Euler Taveira de Oliveira<br /> > <<a
href="mailto:euler@timbira.com">euler@timbira.com</a>>wrote:<br />>> On 01-10-2011 17:44, Daniel Farina
wrote:<br/>>>><br />>>> On Fri, Sep 30, 2011 at 9:30 PM, Tom Lane<<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /> >>>><br />>>>> ISTM it
wouldbe reasonably non-controversial to allow users to issue<br />>>>> pg_cancel_backend against other
sessionslogged in as the same userID.<br />>>>> The question is whether to go further than that, and if so
howmuch.<br /> >>><br />>>> In *every* case -- and there are many -- where we've had people<br
/>>>>express pain, this would have sufficed.<br />>>><br />>> I see. What about passing this
decisionto DBA? I mean a GUC<br /> >> can_cancel_session = user, dbowner (default is '' -- only superuser).
You<br/>>> can select one or both options. This GUC can only be changed by superuser.<br />> <br />> Or how
aboutmaking it a grantable database-level privilege?<br /> > <br />> -- <br />> Robert Haas<br />>
EnterpriseDB:<a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br />> The Enterprise PostgreSQL
Company<br/>> <br />> -- <br />> Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> > To make changes to your
subscription:<br/>> <a
href="http://www.postgresql.org/mailpref/pgsql-hackers">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></div>