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

hi...

> > 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.

unless i misunderstand, the concept is to design the logs such that it is
trivial to convert them into a database, even including tools to do this, not
to actually create a database on the fly.

i'm also supportive of including tools to run standard reports out-of-the-box
on these logs. using pgsql to massage its own logs is pretty sexy, imo =)

> 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.)
> initialization). On the whole, a plain text file in the database
> directory is probably the best bet.

agreed...

> There MUST exist a way to alter the logging level on-the-fly;
> IMHO this is a rock bottom, non negotiable requirement.

whilst i don't think this is MUST, it is EXTREMELY desirable and would make the
logging actually useful for large installations =)

> 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.

why not use pg_options for logging cofig?

> 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.

systems i've dealt with in the past prioritize (as you mentioned) on a numeric
scale to reflect "importance" and the logging level is by default set at a
certain "height"... increasing logging is as easy as changing the threshold..
this has been effective in the past...

the only problem with ONLY relying on thresholds is that its a very coarse
grain method... so when you request a lower level of logging, you often get
inundated with all SORTS of stuff you don't really care/want...

a hybridization between the two approaches might be best.. e.g., each type of
message gets assigned a "criticality", between 1 and 10 perhaps. with 1 being
most critical, and 10 being least.. therefore, the higher you set your logging
level, the more messages you get (logical?)

the default behaviour for each level (1..10) is to let everything though on
that level. but you can apply filters to limit the output...
so you get the ability to define grossly with thresholds (1..10) and finely
(and optionally) with message filters...

> You could do worse than to borrow BIND's syntax for log control.

much worse. =)

--
Aaron J. Seigo
Sys Admin