Re: pg_cancel_backend by non-superuser

From: Kääriäinen Anssi <anssi(dot)kaariainen(at)thl(dot)fi>
To: Daniel Farina <daniel(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_cancel_backend by non-superuser
Date: 2011-10-01 22:47:21
Message-ID: BC19EF15D84DC143A22D6A8F2590F0A78864133047@EXMAIL.stakes.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"""
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-10-01 22:54:37 Re: Bug with pg_ctl -w/wait and config-only directories
Previous Message Mr. Aaron W. Swenson 2011-10-01 22:21:13 Re: Bug with pg_ctl -w/wait and config-only directories