On Tue, Jun 23, 2015 at 1:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@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
