Re: [HACKERS] keeping track of connections
От | Brett McCormick |
---|---|
Тема | Re: [HACKERS] keeping track of connections |
Дата | |
Msg-id | 13685.6518.808420.166699@web0.speakeasy.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] keeping track of connections (dg@illustra.com (David Gould)) |
Ответы |
Re: [HACKERS] keeping track of connections
Re: [HACKERS] keeping track of connections Re: [HACKERS] keeping track of connections |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: