Re: [HACKERS] RFC: Industrial-strength logging (long message) - Mailing list pgsql-hackers

Tim Holloway <mtsinc@southeast.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