Unified logging system for command-line programs - Mailing list pgsql-hackers
From | Peter Eisentraut |
---|---|
Subject | Unified logging system for command-line programs |
Date | |
Msg-id | 6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com Whole thread Raw |
Responses |
Re: Unified logging system for command-line programs
Re: Unified logging system for command-line programs |
List | pgsql-hackers |
I have developed a patch that unifies the various ad hoc logging (message printing, error printing) systems used throughout the command-line programs. Examples: - fprintf(stderr, _("%s: could not open file \"%s\" for writing: %s\n"), - progname, path, strerror(errno)); + pg_log_error("could not open file \"%s\" for writing: %m", path); - if (debug) - fprintf(stderr, - _("%s: file \"%s\" would be removed\n"), - progname, WALFilePath); + pg_log_debug("file \"%s\" would be removed", WALFilePath); Features: - Program name is automatically prefixed. - Message string does not end with newline. This removes a common source of inconsistencies and omissions. - Additionally, a final newline is automatically stripped, simplifying use of PQerrorMessage() etc., another common source of mistakes. - I converted error message strings to use %m where possible. (I had originally intended to implement %m here like elog used to do, but that was thankfully already done elsewhere.) - As a result of the above several points, more translatable message strings can be shared between different components and between frontends and backend, without gratuitous punctuation or whitespace differences. - There is support for setting a "log level". This is not meant to be user-facing, but can be used internally to implement debug or verbose modes, as in the above example. - Lazy argument evaluation, so no significant overhead if logging at some level is disabled. - Bonus: Some color in the messages, similar to gcc and clang. Export PG_COLOR=auto to try it out. The colors are currently hardcoded, so some configuration there might be added. - Common files (common/, fe_utils/, etc.) can handle logging much more simply by just using one API without worrying too much about the context of the calling program, requiring callbacks, or having to pass "progname" around everywhere. Soft goals: - Reduces vertical space use and visual complexity of error reporting in the source code. - Encourages more deliberate classification of messages. For example, in some cases it wasn't clear without analyzing the surrounding code whether a message was meant as an error or just an info. - Concepts and terms are vaguely aligned with popular logging frameworks such as log4j and Python logging. - Future possibilities. Maybe something like log_line_prefix or different log formats could be added. Just a theory right now, but this would make it easier. Non-goals/out of scope: - Flow control. This is all just about printing stuff out. Nothing affects program flow (e.g., fatal exits). The uses are just too varied to do that. Some existing code had wrappers that do some kind of print-and-exit, and I adapted those. It didn't seem worth going any further. It's not fully complete but most of it works well. I didn't do pg_upgrade and pg_ctl yet. pg_dump has some remaining special cases to work through. I tried to keep the output mostly the same, but there is a lot of historical baggage to unwind and special cases to consider, and I might not always have succeeded. One significant change is that pg_rewind used to write all error messages to stdout. That is now changed to stderr. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
pgsql-hackers by date: