Skip site navigation (1) Skip section navigation (2)

Re: We need to log aborted autovacuums

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: We need to log aborted autovacuums
Date: 2010-11-17 22:50:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> I've been trying to diagnose in a production database why certain tables
> never get autovacuumed despite having a substantial % of updates.  The
> obvious reason is locks blocking autovacuum from vacuuming the table ...
> but the trick is we don't log such blocking behavior, at all.  This
> means that there is no possible way for a user to figure out *why* his
> tables aren't getting autovacuumed.

> And yes, this is a common problem.  A quick survey on IRC found 3 active
> users on channel (out of 20 or so) who'd encountered it.  The current
> case I'm looking at is a table with over 70% bloat which hasn't been
> autovacuumed since the database was upgraded a month ago.

> What I'd like to do is add some logging code to autovacuum.c so that if
> log_autovacuum is any value other than -1, failure to vacuum due to
> locks gets logged.   Does this make sense?

It's hard to tell, because you're just handwaving about what it is you
think isn't being logged; nor is it clear whether you have any evidence
that locks are the problem.  Offhand I'd think it at least as likely
that autovacuum thinks it doesn't need to do anything, perhaps because
of a statistics issue.  There *is* an elog(DEBUG3) in autovacuum.c
that reports whether autovac thinks a table needs vacuumed/analyzed ...
maybe that needs to be a tad more user-accessible.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Greg SmithDate: 2010-11-17 23:05:43
Subject: Re: CommitFest 2010-11: Call for Reviewers
Previous:From: Tom LaneDate: 2010-11-17 22:23:54
Subject: Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group