Re: less log level for success dynamic background workers for 9.5 - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: less log level for success dynamic background workers for 9.5
Date
Msg-id 5589B235.8000109@BlueTreble.com
Whole thread Raw
In response to Re: less log level for success dynamic background workers for 9.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: less log level for success dynamic background workers for 9.5  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On 6/23/15 12:21 PM, Tom Lane wrote:
> I concur: if we're to have a flag at all, it should work as Alvaro says.
>
> However, I'm not real sure we need a flag.  I think the use-case of
> wanting extra logging for a bgworker under development is unlikely to be
> satisfied very well by just causing existing start/stop logging messages
> to come out at higher priority.  You're likely to be wanting to log other,
> bgworker-specific, events, and so you'll probably end up writing a bunch
> of your own elog calls anyway (which you'll eventually remove, #ifdef out,
> or decrease the log levels of).

FWIW, I have this problem *constantly* with plpgsql. I put RAISE DEBUGs 
in, but once you have those in enough places SET 
client_min_messages=debug becomes next to useless because of the huge 
volume of spew.

What I'd like is a way to add an identifier to ereport/RAISE so you 
could turn on individual reports. If we had that we'd just make these 
particular ereports DEBUG1 and not worry about it because you could 
easily turn them on when needed.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: btree_gin and BETWEEN
Next
From: Jim Nasby
Date:
Subject: Re: pg_stat_*_columns?