On Thu, Oct 21, 2010 at 3:14 PM, Nick wrote:
> I have a production server running postgres 8.3.11. I did a dump all
> and loaded up postgres 9.0.1 on another server. On the new server,
> the postgres autovacuum launcher process eats up an insane amount of
> ram (I have seen 17G virt with 6.5G re
Nick wrote:
> I have a production server running postgres 8.3.11. I did a dump
> all and loaded up postgres 9.0.1 on another server. On the new
> server, the postgres autovacuum launcher process eats up an insane
> amount of ram (I have seen 17G virt with 6.5G res).
You're not looking at thi
I have a production server running postgres 8.3.11. I did a dump all
and loaded up postgres 9.0.1 on another server. On the new server,
the postgres autovacuum launcher process eats up an insane amount of
ram (I have seen 17G virt with 6.5G res). On the older version, it's
at a reasonable 9MB re
This is a web app, so the username is unknown until the user actually logs in.
It would be ideal if pg_stat_activity contained the current role.
Until then, I'll go with your second recommendation.
Thanks for such a quick and useful reply.
Ken
On 2010-10-21, at 2:18 PM, Tom Lane wrote:
> Ken L
Ken Lalonde writes:
> Is there any way to determine if a given role has any active sessions?
Not if you're using SET ROLE. pg_stat_activity will show you the
login role names for active sessions. Do you really need SET ROLE
rather than logging in with the appropriate username?
There are going
I need to track db activity by role. All web-related connections to the db
use the same user name.
When a user logs in via the web, the application code runs:
SET ROLE "n"
where n is the ID value for the user in the "users" table.
(These numeric roles are created dynamically as needed).
