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
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 |