Re: jsonlog logging only some messages? - Mailing list pgsql-hackers

From Greg Stark
Subject Re: jsonlog logging only some messages?
Date
Msg-id CAM-w4HMvx0JC1EoFA5vJd1-MCLKWS-LPg2Y7C5N=gbQK3Wt9rQ@mail.gmail.com
Whole thread Raw
In response to Re: jsonlog logging only some messages?  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On 27 February 2018 at 16:50, Greg Stark <stark@mit.edu> wrote:
> On 27 February 2018 at 02:04, Michael Paquier <michael@paquier.xyz> wrote:
>> On Mon, Feb 26, 2018 at 05:38:56PM +0000, Greg Stark wrote:
>>
>> Hm.  I have just loaded jsonlog on a 9.6 and 10 instance where
>> log_checkpoints is enabled with this background worker which logs a
>> simple string every 10s:
>> https://github.com/michaelpq/pg_plugins/tree/master/hello_world
>>
>> Both checkpoint logs and the logs of the bgworker are showing up for me.
>
> Weird. I guess I have some more debugging with gdb to do.

I think I see what's going on. The log_min_messages is set to the
default value of warning. Which is a higher level than "LOG" so this
code in jsonlog.c is ignoring these messages:

if (edata->elevel < log_min_messages)
return;


But the normal processing for logs uses is_log_level_output to compare
error levels with log_min_messages which treats LOG (and
LOG_SERVER_ONLY) as logically equivalent to ERROR:

/*
 * is_log_level_output -- is elevel logically >= log_min_level?
 *
 * We use this for tests that should consider LOG to sort out-of-order,
 * between ERROR and FATAL.  Generally this is the right thing for testing
 * whether a message should go to the postmaster log, whereas a simple >=
 * test is correct for testing whether the message should go to the client.
 */
static bool
is_log_level_output(int elevel, int log_min_level)
{
if (elevel == LOG || elevel == LOG_SERVER_ONLY)
{
if (log_min_level == LOG || log_min_level <= ERROR)
return true;
}
else if (log_min_level == LOG)
{
/* elevel != LOG */
if (elevel >= FATAL)
return true;
}
/* Neither is LOG */
else if (elevel >= log_min_level)
return true;

return false;
}


-- 
greg


pgsql-hackers by date:

Previous
From: Julian Markwort
Date:
Subject: Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)
Next
From: Tomas Vondra
Date:
Subject: Re: WIP: BRIN multi-range indexes