Gourish Singbal <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
