Re: vacuuming template0 gave ERROR - Mailing list pgsql-admin

From Tom Lane
Subject Re: vacuuming template0 gave ERROR
Date
Msg-id 9822.1135612972@sss.pgh.pa.us
Whole thread Raw
In response to vacuuming template0 gave ERROR  (Gourish Singbal <gourish@gmail.com>)
Responses Re: vacuuming template0 gave ERROR
List pgsql-admin
Gourish Singbal <gourish@gmail.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

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: reg:lseek&read ..pls
Next
From: Gourish Singbal
Date:
Subject: Re: vacuuming template0 gave ERROR