Thread: sanity check error for pg_dump

Currently we  have upgraded postgres from 7.0.2 to postgres7.0.3
version  on Linux 2.2.16-22smp #1 SMP  2000 i686 unknown .
And we take backup of our postgres database on daily bases through
cron using following scripts

*****
# Script to backup the minx databases

daymon="`date +%d``date +%b`"
BACKPATH='/usr/local/pgsql/minx/backup'

# Create dump of 250 and 300 databases

pg_dump minx250 -f $BACKPATH/$daymon-250-dump.ti
pg_dump minx300 -f $BACKPATH/$daymon-300-dump.ti

# Compress the backups

compress $BACKPATH/$daymon-250-dump.ti
compress $BACKPATH/$daymon-300-dump.ti

***** End Of Script ***********

The total size of our database is 3.8G . and available disk space
is 4.8 G
We have recently started getting following error messages

failed sanity check, table arind was not found
failed sanity check, table inpart was not found

 due to which pg_dump  process does not get complete.

  We have tried droping and recreating the table which has caused
error .  but it didn't help . Vacuum goes through for those tables.

Please tell us what has to be done in such instance .

Regards,
Pragati

PRAGATI SAVAIKAR <pragati@phil.com.sg> writes:
> We have recently started getting following error messages
> failed sanity check, table arind was not found
> failed sanity check, table inpart was not found
>  due to which pg_dump  process does not get complete.

It's a good bet that these tables belong to a user who's been dropped
from pg_shadow.  Check their pg_class entries to see what the relowner
field is.  You can either create a new user entry with a matching
usesysid value, or change the relowner fields to match an existing user.

            regards, tom lane