While reviewing Jeff's notice_lock_waits patch, I came across his comment
about having a general facility for promoting selected LOG messages. So I
thought I should post it here, even though the patch is probably far from
being accepted in Postgres.

I recently wrote a patch for Postgres-XL to do exactly this and I found it
very useful, especially while debugging race conditions and problems with
ongoing sessions. I'm attaching a patch rebased on PG-master. It works, but
TBH I don't think it's anywhere close for being acceptable in PG. But I
hope this is good enough to show how this can be done with minimal changes
and spark ideas.

The patch uses some preprocessing and scripting magic to assign distinct
identifiers to each module (a subdir in the source code), to each file and
to each elog message. It then provides a set of functions by which an user
can increase/decrease/set log levels for either individual messages or all
messages within a source file or source module. The log levels can be
changed only for specific backends or all current or future backends. If
you configure with --enable-genmsgids switch, a MSGMODULES and MSGIDS file
is created in $srcdir, which can later be used to know ids assigned to
various modules/messages.

Now there are several problems with the patch:

- I don't know if it will work for anything other than clang and gcc (I've
tested those two, but only specific versions)
- The shared memory representation for msgs is not at all optimal and with
a large value of max_connections, it can quickly go out of control. But I
believe we can find a better representation without losing runtime
- The APIs themselves can be significantly improved.
- MSGMODULES and MSGIDS should probably be some sort of a view that user
can readily access without requiring access to the environment where it was
- Right now it only supports changing levels for DEBUG[1-5] and LOG
messages. But that could be easily extended to cover INFO or NOTICE.
- The patch should probably have many more comments
- Finally, I don't know if better and more elegant ways exist to
automatically assigning module/file/msgids. I couldn't think of any without
making excessive changes to all source files and hence did what I did. That
does not mean better ways don't exists.


 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment: pg_msgids.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to