Re: More logging for autovacuum
От | Sawada Masahiko |
---|---|
Тема | Re: More logging for autovacuum |
Дата | |
Msg-id | CAD21AoDotHddaYBDJy2YAcbUAW4Rc2=GR4SgQXUWvNnQouszsA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: More logging for autovacuum (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: More logging for autovacuum
(Gurjeet Singh <gurjeet@singh.im>)
|
Список | pgsql-hackers |
On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh <gurjeet@singh.im> wrote: >> >> On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera >> <alvherre@commandprompt.com> wrote: >>> >>> Gregory Stark wrote: >>> > >>> > I'm having trouble following what's going on with autovacuum and I'm >>> > finding >>> > the existing logging insufficient. In particular that it's only logging >>> > vacuum >>> > runs *after* the vacuum finishes makes it hard to see what vacuums are >>> > running >>> > at any given time. Also, I want to see what is making autovacuum decide >>> > to >>> > forgo vacuuming a table and the log with that information is at DEBUG2. >>> >>> So did this idea go anywhere? >> >> >> Assuming the thread stopped here, I'd like to rekindle the proposal. >> >> log_min_messages acts as a single gate for everything headed for the >> server logs; controls for per-background process logging do not exist. If >> one wants to see DEBUG/INFO messages for just the Autovacuum (or >> checkpointer, bgwriter, etc.), they have to set log_min_messages to that >> level, but the result would be a lot of clutter from other processes to >> grovel through, to see the messages of interest. >> > > I think that will be quite helpful. During the patch development of > parallel sequential scan, it was quite helpful to see the LOG messages > of bgworkers, however one of the recent commits (91118f1a) have > changed those to DEBUG1, now if I have to enable all DEBUG1 > messages, then what I need will be difficult to find in all the log > messages. > Having control of separate logging for background tasks will serve such > a purpose. > >> The facilities don't yet exist, but it'd be nice if such parameters when >> unset (ie NULL) pick up the value of log_min_messages. So by default, the >> users will get the same behaviour as today, but can choose to tweak per >> background-process logging when needed. >> > > Will this proposal allow user to see all the messages by all the background > workers or will it be per background task. Example in some cases user > might want to see the messages by all bgworkers and in some cases one > might want to see just messages by AutoVacuum and it's workers. > > I think here designing User Interface is an important work if others also > agree > that such an option is useful, could you please elaborate your proposal? +1 I sometime want to set log_min_messages per process, especially when less than DEBUG level log is needed. It's not easy to set log level to particular process from immediately after beginning of launch today. Regards, -- Sawada Masahiko
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Oskari SaarenmaaДата:
Сообщение: Re: Repeated pg_upgrade buildfarm failures on binturon