Content-Type: text/plain; charset=UTF-8
Cc: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>,
	Ireneusz Pluta <ipluta@wp.pl>
Subject: Re: Autovacuum and invalid page header
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kevin Grittner <kevin.grittner@wicourts.gov>
In-reply-to: <4BEBC57002000025000316A3@gw.wicourts.gov>
References: <4BEA8CD0.8070108@wp.pl>
 <4BEBC57002000025000316A3@gw.wicourts.gov>
Date: Fri, 14 May 2010 00:40:41 -0400
Message-Id: <1273811839-sup-7071@alvh.no-ip.org>
User-Agent: Sup/0.11
Content-Transfer-Encoding: 8bit

Excerpts from Kevin Grittner's message of jue may 13 10:25:04 -0400 2010:
> Ireneusz Pluta <ipluta@wp.pl> wrote:
>  
> > many different autovacuums on the same table cycling in start-fail
> > scenario because of invalid page headers of some indexes of the
> > table. Manual VACUUM VERBOSE said me that, now I can also see that
> > in related ERROR-CONTEXT log message pairs. I dropped the damaged
> > indexes and now that autovacuum seems to continue without
> > repeating itself.

> That does sound like an area where there might be room for
> improvement within PostgreSQL;

Yeah, maybe we should make it put the failed table at the end of the
list, for the next run.  This is not simple to implement, if only
because autovac workers don't have any way to persist state from one run
to the next.  But this kind of thing causes enough problems that it's
probably worth it.

One thing to keep in mind, though, is that a persistent error in a
single table is enough to keep a database's datfrozenxid from advancing,
and thus shut down in case the wraparound horizon comes too close.  So
perhaps what we need is more visibility into autovacuum problems.
--