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
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Information of pg_stat_ssl visible to all users