Re: Override compile time log levels of specific messages/modules

On 6 Sep. 2016 17:57, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> wrote:
>
>
>
> On Tue, Sep 6, 2016 at 3:06 PM, Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>
wrote:
>>
>>
>> I think it's worth looking at how Java handles logging. We can't achieve
an exact parallel in C as we don't really have a class hierarchy ... but we
do have subsystems roughly grouped by file and directory structure.
>
> Sure. In some large, popular enterprise softwares I've worked with many
years ago, we used to define modules within each source file and then
manually assign distinct integer IDs to each message and then provide
various utilities to turn on/off specific messages or range of messages
within a module.

Yeah, there same has been discussed for Pg many times and firmly shot down
each time. I certainly see the argument against making specific elog calls
part of a sort of api people might expect to be stable ish. That's what we
have ERRCODE / SQLSTATE for right? Concerns about backpatch pain were also
raised. Probably more. I'm not especially for or against it myself, just
saying that based on past discussion such a proposal isn't likely to fly.

I think something automatic that we clearly define as unstable and not to
be relied upon would be preferable. Plus we already have much of the
infrastructure in elog.c as used by errcontext etc.

> Well, __FUNCTION__ expands to function name and lookup based on string
identifiers will always be costly, especially if you want to sprinkle the
code with lot many debug messages. Same with __FILE__. I believe we need an
unique integer constant to make it a fast, O(1) lookup. I couldn't find any
other method to do that when I wrote the facility and hence did what I did.

Yeah. High performance logging and filtering isnt easy. Looking at existing
C logging libraries with dynamic filtering might be informative. Though I
can't imagine there being agreement to adopt one, this must be a reasonably
solved problem...

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