Skip site navigation (1) Skip section navigation (2)

Re: Giving postgres roles 'sudo'-like access

From: Craig James <craig_james(at)emolecules(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Giving postgres roles 'sudo'-like access
Date: 2011-12-19 18:46:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On 12/19/11 10:04 AM, Mario Splivalo wrote:
> I need to have postgres role to be able to cancel queries run by that
> same role.
> I know that I can kill the client connection that started the query, but
> I also need to have that role connect to postgres and kill some of it's
> running queries.
> It's on postgres 9.1.1, running on Debian Squeeze.
> One idea that comes to mind is to have a special user account on the box
> which would have sudo privileges to the script which will issue 'sh
> postgres -c 'psql -c "select pg_cancel_backend(<pid>)"', but before that
> run checks that<pid>  is actually owned by correct role, etc, etc. But,
> all that seems very fishy.
> Has anyone had similar requests, and maybe solved them somehow?

First of all, you really don't want to do this.  If there's any other way, find it.

In our case, we use a third-party library that sometimes gets stuck on problems that would take a virtually infinite time to solve, and for reasons having to do with NP-complete theory, you can't easily detect them ahead of time.  So....

Backend Postgres processes run as the Postgres user, so they have permission to kill each other.  You write an add-on function that just kills a process:

   select my_kill_backend(pid);

Naturally, this is very dangerous. There are all sorts of security implications.  You want to use signal 2 or 15, not 9.  And so forth.


In response to


pgsql-admin by date

Next:From: Lukasz BrodziakDate: 2011-12-19 22:01:13
Subject: Re: information_schema.tables view does not exist
Previous:From: Mario SplivaloDate: 2011-12-19 18:04:13
Subject: Giving postgres roles 'sudo'-like access

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group