Re: less log level for success dynamic background workers for 9.5
От | Robert Haas |
---|---|
Тема | Re: less log level for success dynamic background workers for 9.5 |
Дата | |
Msg-id | CA+TgmoYih9EzhDF63dF8uRQCMjwBk4krBeyw9QR26WUd7RjRuQ@mail.gmail.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 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
В списке pgsql-hackers по дате отправления: