On Tue, Mar 27, 2012 at 1:46 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Excerpts from Robert Haas's message of mar mar 27 14:38:47 -0300 2012: >> On Tue, Mar 27, 2012 at 1:26 PM, Daniel Farina <dan...@heroku.com> wrote: >> > On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas <robertmh...@gmail.com> wrote: >> >> I think the more important question is a policy question: do we want >> >> it to work like this? It seems like a policy question that ought to >> >> be left to the DBA, but we have no policy management framework for >> >> DBAs to configure what they do or do not wish to allow. Still, if >> >> we've decided it's OK to allow cancelling, I don't see any real reason >> >> why this should be treated differently. >> > >> > Is there a hypothetical DBA that doesn't want a mere-mortal user to be >> > able to signal one of their own backends to do "cancel query, rollback >> > the transaction, then close the socket"? If so, why? >> >> Well, I guess if you have different people sharing the same user-ID, >> you probably wouldn't want that. >> >> But maybe that's not an important case. > > Isn't it the case that many web applications run under some common > database user regardless of the underlying webapp user?
Yes. > I wouldn't say > that's an unimportant case. Granted, the webapp user wouldn't have > permission to run arbitrary queries in the first place. Right. That's why I'm thinking maybe it doesn't matter. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
