From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tim Holloway <mtsinc(at)leading(dot)net> |
Cc: | pgsql-admin(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] RFC: Industrial-strength logging (long message) |
Date: | 1999-10-23 17:25:05 |
Message-ID: | 1734.940699505@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tim Holloway <mtsinc(at)southeast(dot)net> writes:
> Request For Comments: Towards an industrial-strength
> logging facility
Sounds pretty good overall.
> This depends. I like a console-style listing, as my needs are
> simple. Others would prefer that the log be itself a database.
Note that logging into a table is harder than you might think.
For example: (1) The postmaster cannot touch tables at all, so
no events detected in the postmaster could be logged that way.
(2) No events detected during a transaction that ultimately
aborts will be successfully logged. (3) Logging events such as
"server failure" would be quite risky --- if the server has
suffered internal state corruption then it could manage to
corrupt the log table entirely while it's trying to add its
last-dying-breath report.
Fortunately none of these problems apply to stderr, syslog,
or plain-text-file reporting channels.
> There are 3 types of information in the logging
> configuration file (which may, but likely won't, be part of
> pg_hba.conf)
No, it should definitely not be part of pg_hba.conf, it should
be a separate configuration file. (pg_hba.conf has a syntax too
simple to be easily extensible.)
Another possibility is to keep the config info in a system table, but
that would have a number of drawbacks (the postmaster cannot read
tables, nor can a backend that's just starting up and hasn't finished
initialization). On the whole, a plain text file in the database
directory is probably the best bet.
> Logging info is read at startup. There may
> exist signals that cause it to be reread, but not just yet.
There MUST exist a way to alter the logging level on-the-fly;
IMHO this is a rock bottom, non negotiable requirement.
A production system can't restart the postmaster just to tweak
the logging level up or down for investigation of a problem.
Whether it's a signal or something else remains to be determined.
We have pretty nearly used up all the available signal numbers :-(.
I suppose that whichever signal is currently used to trigger
rereading of the pg_options configuration file could also trigger
re-reading of the logging config file.
> To avoid potential loss
> of critical info, any message not explicitly routed at least
> once gets reported on the default channel - stderr/syslog,
> unless otherwise configured.
Hmm, so I'd have to explicitly discard every message I didn't want to
hear about? I think that "forced display" like this should only happen
for high-severity messages, not for routine junk. There doesn't seem to
be any notion of message importance in your design, but I think there
should be. Most people would probably prefer to filter on an importance
level, only occasionally resorting to calling out specific message types.
> Especially of interest is what the shape of the config file should be.
> Is the the pseudo-HTML format shown good?
You could do worse than to borrow BIND's syntax for log control.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bernard Frankpitt | 1999-10-23 17:49:16 | Re: [HACKERS] postgres inode q's |
Previous Message | Oleg Broytmann | 1999-10-23 12:44:35 | GPL vs BSD vs SCSL |