Re: less log level for success dynamic background workers for 9.5
От | Jim Nasby |
---|---|
Тема | Re: less log level for success dynamic background workers for 9.5 |
Дата | |
Msg-id | 5589B235.8000109@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: less log level for success dynamic background workers for 9.5 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: less log level for success dynamic background workers
for 9.5
|
Список | 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 по дате отправления: