Re: [HACKERS] RFC: Industrial-strength logging (long message)

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

Responses

Browse pgsql-hackers by date

  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