Re: Does pg_dump ignore indexes?

"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