Re: vacuum error

From: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: vacuum error
Date: 2007-03-06 21:19:15
Message-ID: 200703061419.15855.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tuesday March 6 2007 12:20 pm, Peter Eisentraut wrote:
> Ed L. wrote:
> > I am seeing the following error in pgsql 8.1.2:
> >
> > ERROR: could not access status of transaction 3229475082
> > DETAIL: could not open file "pg_clog/0C07": No such file or
> > directory
> >
> > What does it mean, and what should I do about it?
>
> 1. Read this thread:
> http://archives.postgresql.org/pgsql-general/2007-02/msg00820.
>php
>
> 2. Upgrade to the latest 8.1.* release.
>
> 3. If that doesn't help, check your system for faulty
> hardware, in particular for bad RAM.

This is a 200gb DB with ~300 transactions/second serving 5 busy
facilities, so downtime comes at a premium. We have some
maintenance downtime planned for 2 weeks from now. I'm trying
to understand if this can wait that long.

It appears the only failure occurs during an autovacuum-initiated
"VACUUM FREEZE" on template0 when it hits the pg_statistics
table. However, that abort appears to be causing autovacuum to
skip all its other duties as it endlessly restarts and fails
again.

Do I care if template0 gets a "VACUUM FREEZE"?

Assuming not, is there a simple way to make autovacuum skip over
template0 so it can tend to the important data in the other
databases?

Is restarting with 8.1.8 a known solution for this problem? Or
is an initdb required to fix it?

If initdb is required, we might as well move to the latest stable
8.2 version. I understand my options to minimize downtime to be
limited to async replication. Other ideas?

BTW, the RAM looks good.

TIA.
Ed

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2007-03-06 22:53:47 Re: vacuum error
Previous Message Tom Lane 2007-03-06 21:18:11 Re: postgres slower on nested queries