On Wed, 3 June 1998, at 01:05:17, David Gould wrote:
> I am curious, what is it you are trying to accomplish with this? Are you
> trying to build a persistant log that you can query later for billing
> or load management/capacity planning information? Are you trying to monitor
> login attempts for security auditing? Are you trying to catch logins in
> real time for some sort of middleware integration?
The problem is that when I do a process listing for the postgres user,
I see many backends. There's no (convenient) way to see what those
backends are doing, what db they're connected to or the remote
host/postgres user.
My required functionality is this: a list of all backends and
connection details. IP, queries issued, listens/notifications
requested/served, bytes transfered, postgres user, db, current query,
client version, etcetcetc.
What problem am I trying to solve? It is purely a desire for this
information. I also feel it will help be debug problems. It would be
nice to track down my clients that are now failing because of password
authentication, but I do admit that this would not help much.
What I shall be doing is hacking libpq to report the name of the
process and related information like environment when connecting to a
database. This would let me track down those programs. As it is, I
have programs failing, and I don't know which ones. Obviously they
aren't very crucial, but it would be nice to know how much more it is
than me typing 'psql' on the host and expecting to connect.
Obviously, this is unrelated. But it is purely a desire for
information. The more info the better. The debug log is quite
henious when trying to figure out what's going on, especially with
lots of connections.
On another unrelated note, the postmaster has been dying lately,
leaving children hanging about. I thought something might be
corrupted (disk full at one point) so I did a dump/reload. We'll see
what happens.
Call it a feature.