Re: More logging for autovacuum

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Gurjeet Singh <gurjeet(at)singh(dot)im>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More logging for autovacuum
Date: 2015-07-04 05:30:33
Message-ID: CAA4eK1L8eG5EfZy+gYJJngSwooOD++TuWVC_MdaVtZ2e6oeQhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh <gurjeet(at)singh(dot)im> wrote:
>
> On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera <
alvherre(at)commandprompt(dot)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?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-07-04 05:33:07 Re: Determine operator from it's function
Previous Message Jan de Visser 2015-07-04 01:33:11 Re: Idea: closing the loop for "pg_ctl reload"