""" 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. """ I would be a step in the right direction if the DB owner would see all queries to the DB in pg_stat_activity. - Anssi -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers