From: | Gourish Singbal <gourish(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: vacuuming template0 gave ERROR |
Date: | 2005-12-27 07:05:43 |
Message-ID: | 674d1f8a0512262305g3e2bfb81t420482ea981b6e14@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-performance |
Tom,
I got the followign Erorr when i tried to trucate the table.
/usr/local/pgsql/bin/postgres -D data -O -o standalone_log template0
2005-12-26 22:48:12 ERROR: expected one dependency record for TOAST table,
found 0
2005-12-26 22:48:31 ERROR: could not access status of transaction
1107341112
DETAIL: could not open file "/home/postgres/data/pg_clog/0420": No such
file or directory
2005-12-26 22:48:41 LOG: shutting down
2005-12-26 22:48:41 LOG: database system is shut down
please suggest ?.
On 12/26/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Gourish Singbal <gourish(at)gmail(dot)com> writes:
> > Got the following ERROR when i was vacuuming the template0 database.
>
> Why were you doing that in the first place? template0 shouldn't ever
> be touched.
>
> > postgresql server version is 7.4.5
>
> The underlying cause is likely related to this 7.4.6 bug fix:
>
> 2004-10-13 18:22 tgl
>
> * contrib/pgstattuple/pgstattuple.c,
> src/backend/access/heap/heapam.c,
> src/backend/utils/adt/ri_triggers.c (REL7_4_STABLE): Repair
> possible failure to update hint bits back to disk, per
> http://archives.postgresql.org/pgsql-hackers/2004-10/msg00464.php.
> I plan a more permanent fix in HEAD, but for the back branches it
> seems best to just touch the places that actually have a problem.
>
>
> > INFO: vacuuming "pg_catalog.pg_statistic"
> > ERROR: could not access status of transaction 1107341112
> > DETAIL: could not open file "/home/postgres/data/pg_clog/0420": No such
> > file or directory
>
> Fortunately for you, pg_statistic doesn't contain any irreplaceable
> data. So you could get out of this via
>
> TRUNCATE pg_statistic;
> VACUUM ANALYZE; -- rebuild contents of pg_statistic
> VACUUM FREEZE; -- make sure template0 needs no further vacuuming
>
> Then reset template0's datallowconn to false, and get rid of that code
> to override it. And then update to a more recent release ;-)
>
> (I don't recall exactly what rules 7.4 uses, but likely you'll find that
> you need to run a standalone backend with -O switch to perform
> TRUNCATE on a system catalog.)
>
> regards, tom lane
>
--
Best,
Gourish Singbal
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-27 07:16:18 | Re: vacuuming template0 gave ERROR |
Previous Message | Tom Lane | 2005-12-26 16:02:52 | Re: vacuuming template0 gave ERROR |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-27 07:16:18 | Re: vacuuming template0 gave ERROR |
Previous Message | Tom Lane | 2005-12-26 23:52:08 | Re: Performance hit on large row counts |