From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kevin Grittner <kevin.grittner@wicourts.gov>
Cc: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Cc: Ireneusz Pluta <ipluta@wp.pl>
Subject: Re: Autovacuum and invalid page header
Date: Fri, 14 May 2010 00:40:41 -0400
Message-ID: <1273811839-sup-7071@alvh.no-ip.org> (raw)
In-Reply-To: <4BEBC57002000025000316A3@gw.wicourts.gov>
References: <4BEA8CD0.8070108@wp.pl>
<4BEBC57002000025000316A3@gw.wicourts.gov>
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.
--
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: alvherre@alvh.no-ip.org, kevin.grittner@wicourts.gov, ipluta@wp.pl
Subject: Re: Autovacuum and invalid page header
In-Reply-To: <1273811839-sup-7071@alvh.no-ip.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox