At 05:23 +0200 on 12/10/1999, Bruce Momjian wrote:
> The postmaster/postgres -d option can echo tons of information you many
>need.
> Postmaster -d will show connections, and postgres -d shows queries and
> other info. Postgres -E is good too.
If I may be so bold, I must say that the backend log you mention is almost
completely useless - at least to me.
The information is spread thin, and you can't get the essential data, which
is a timestamp, user operation performed, success/failure and reason. If I
need to find when somebody issued a harmful delete, so as to know how long
I've been without my pants, so to speak, the current log format is a direct
route to insanity. The same goes for finding out the reason for some
strange error message. Which of the queries caused it? Which session did
that query belong to? Everything is mixed up, and topped with a lot of
information that means nothing to the non-author (dead processes reaped?).
Something akin to a webserver log would have been much more useful:
<DATE> <TIME> <USER> <SESSION-ID> <HOST-ADDRESS> <OPERATION> <STATUS>
<REASON>. Like:
1999-10-12 10:00:32.15 herouth 8833 123.456.78.90 "Initiating connection"
success ""
1999-10-12 10:00:37 herouth 8833 123.456.78.90 "INSERT INTO animals VALUES
'badger';" failure "Permission on table animals denied to herouth"
Etc.
The session-id can probably be the process id of the backend assigned to
the operation. This would allow tracking a session through the log,
something I find a bit hard in the current configuration.
A debug log is a different thing, done for purposes of, well, debugging,
rather than simple tracking. It should be handled separately, and may
contain information that speaks to developers as well. The log may not.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
************
