From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: less log level for success dynamic background workers for 9.5 |
Date: | 2015-06-23 19:23:33 |
Message-ID: | 5589B235.8000109@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-06-23 19:36:14 | Re: pg_stat_*_columns? |
Previous Message | Tom Lane | 2015-06-23 19:20:14 | Re: btree_gin and BETWEEN |