On Tue, Jun 23, 2015 at 1:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: >> Robert Haas wrote: >>> Well, if the flag is BGWORKER_QUIET, then the default behavior remains >>> unchanged, but when that flag is used, the log level is reduced to >>> DEBUG1. That has the advantage of not breaking backward >>> compatibility. But I'm not sure whether anyone cares if we just break >>> it, and it's certainly simpler without the flag. > >> I vote we do it the other way around, that is have a flag BGWORKER_VERBOSE. >> This breaks backwards compatibility (I don't think there's too much >> value in that in this case), but it copes with the more common use case >> that you want to have the flag while the worker is being developed; and >> things that are already working don't need to change in order to get the >> natural behavior. > > 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).
Yeah. So let's just change it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers