On 24 June 2015 at 03:23, Jim Nasby <jim.na...@bluetreble.com> wrote: > 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.
So, log identifiers/classifiers, essentially. Message numbers have been discussed before with regards to core and rejected consistently. I don't think it's really come up in terms of PLs and user-defined functions. I've certainly had similar issues to you w.r.t. to debug messages from user-level code, and wanted to be able to enable one particular log line, all log output from a particular function, or all log output from a particular extension / all functions in a schema. I think it's a whole separate topicto Pavel's original proposal though, and really merits a separate thread. For Pavel's issue I'm all in favour of just changing the log message, I think LOG is way too high for something that's internal implementation detail. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers