From: | Eric Ridge <ebr(at)tcdi(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Pgsql-General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: ps output and postgres |
Date: | 2004-02-12 16:29:39 |
Message-ID: | A76962BC-5D78-11D8-984A-000A95BB5944@tcdi.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Feb 11, 2004, at 10:00 PM, Bruce Momjian wrote:
> No one really has thought of that before. We could do it, though there
> are admin reasons for restricting that ability. If we said only
> superusers could change it, it wouldn't be very useful.
That's a good point.
> It would be cool if SET could change it, but it seems that would make
> it pretty
> useless for administrator usage.
Ran into a situation yesterday where all connections were exhausted on
a development database, and thanks to our nat-ing firewall, couldn't
tell where all the connections were coming from. It made me think that
intelligently mucking with the ps output might have made things easier
for me to find the person to yell at.
One could just as easily report info like "real" client ip, client
application state, etc, to a table, but having that stuff via 'ps' just
seemed like a cool idea.
In addition, some of our applications have a few background threads
that maintain persistent connections to the database. Being able to
logically label those processes would make it easier to identify which
backend processes are still connected.
eric
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-02-12 16:54:16 | Re: ps output and postgres |
Previous Message | scott.marlowe | 2004-02-12 16:24:45 | Re: Not using index |