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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: btree_gin and BETWEEN
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: pg_stat_*_columns?