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

Re: Proposal to sync SET ROLE and pg_stat_activity

From: Grant Finnemore <grant(at)guruhut(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Euler Taveira de Oliveira <euler(at)timbira(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal to sync SET ROLE and pg_stat_activity
Date: 2008-08-28 08:36:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Hi Bernd,

Bernd Helmle wrote:
> --On Mittwoch, August 27, 2008 09:35:03 +0200 Grant Finnemore 
> <grant(at)guruhut(dot)com> wrote:
>> I have a session pool, where all connections to the database are
>> obtained as a superuser. On issuing connections to the client, we
>> invoke either SET ROLE or SET SESSION AUTHORIZATION and switch to
>> a role with less permissions. This means that we don't have to
>> reserve a connection per user, and we can still use the database
>> access restrictions.
> But you have to ensure that your session pool is smaller than 
> max_connections, since this will eat up superuser_reserved_connections 
> and would make administrator intervention  impossible under certain 
> circumstances.
Yes, but that's the easy part. Any reasonable pooling software allows
you to set max connections.

> And why do you need to hack pg_stat_activity, isn't it possible to plug 
> your own view in?
Well, pg_stat_activity isn't really the problem here, because as you
point out, it's just a view, and I could certainly redefine the view.
The limiting factor is that the backend doesn't push the role name
changes to the stats subsystem for either SET ROLE or SET SESSION

An alternative to changing the current behaviour would be to introduce
new variables in the backend structures that are sent to the stats
subsystem, and which could be read by as yet undefined functions. This
would keep existing behaviour, but allow others to obtain the
alternative behaviour through the creation of a separate view.


In response to


pgsql-hackers by date

Next:From: Martin PihlakDate: 2008-08-28 09:32:14
Subject: Re: Patch: plan invalidation vs stored procedures
Previous:From: Bernd HelmleDate: 2008-08-28 08:04:06
Subject: Re: Proposal to sync SET ROLE and pg_stat_activity

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