Re: More logging for autovacuum

From: Gurjeet Singh <gurjeet(at)singh(dot)im>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: 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-01 23:11:16
Message-ID: CABwTF4X6wD2FOoWXP5kYL3uGbBQ7sEZ05i39xPXEbY+4GLPPfg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

Absent such a feature, one hack is to set the desired log_min_messages
value in conf file and send SIGHUP to just the process of interest and
revert the conf file back; but it's a hack.

Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-07-02 00:58:20 Re: drop/truncate table sucks for large values of shared buffers
Previous Message Andres Freund 2015-07-01 23:09:37 Re: Raising our compiler requirements for 9.6