"Vilson farias" <vilson.farias@digitro.com.br> writes:
> Check this out :
> [postgres@dgtao backup]$ /usr/bin/vacuumdb --analyze --verbose -d relatorio
> NOTICE: --Relation pg_type--
> NOTICE: Pages 4: Changed 0, reaped 1, Empty 0, New 0; Tup 274: Vac 0,
> Keep/VTL 0/0, Crash 0, UnUsed 10, MinLen 105, MaxLen 114; Re-using:
> Free/Avail. Space 1180/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.03u sec.
> NOTICE: Index pg_type_typname_index: Pages 10; Tuples 274: Deleted 0. CPU
> 0.02s/0.01u sec.
> NOTICE: Index pg_type_oid_index: Pages 5; Tuples 274: Deleted 0. CPU
> 0.00s/0.01u sec.
> ... lots of...
> NOTICE: --Relation cham_chamada--
> NOTICE: Rel cham_chamada: TID 4/1: OID IS INVALID. TUPGONE 1.
> NOTICE: Rel cham_chamada: TID 4/2: OID IS INVALID. TUPGONE 1.
> ....3 to 56...
> NOTICE: Rel cham_chamada: TID 4/57: OID IS INVALID. TUPGONE 1.
> NOTICE: Rel cham_chamada: TID 4/58: OID IS INVALID. TUPGONE 1.
> pqReadData() -- backend closed the channel unexpectedly.
Looks like you've got some corrupted data in that table :-(.
If you have a backup, you should restore this table from backup. Or you
could try dumping just this table (pg_dump -t cham_chamada relatorio).
If the results look correct, drop the table and reload it from the dump.
If you are running a Postgres version earlier than 7.0.3, I'd strongly
advise updating to 7.0.3 ASAP. There are several critical fixes in
7.0.3, including one for a VACUUM problem that might cause this sort of
corruption, depending on what your update patterns are like.
regards, tom lane
