Thread: vaccum db fail

vaccum db fail

From
Matthew Terenzio
Date:
Trying vacuumdb eventuallydisplays this:


ERROR:  catalog is missing 3 attribute(s) for relid 31457
vacuumdb: vacuum  databasename failed

There is another thread which states this is a corrupted systems
catalog. Is this definitely the case? Does it mean I need to re-build
the database? Re-install?

Thanks.


Re: vaccum db fail

From
Lonni J Friedman
Date:
I honestly have no idea what that error means, however I'd imagine
that you should be able to dump the DB, and reimport it as a last
resort to fixing this.


On Tue, 28 Dec 2004 18:33:24 -0500, Matthew Terenzio
<webmaster@localnotion.com> wrote:
> Trying vacuumdb eventuallydisplays this:
>
> ERROR:  catalog is missing 3 attribute(s) for relid 31457
> vacuumdb: vacuum  databasename failed
>
> There is another thread which states this is a corrupted systems
> catalog. Is this definitely the case? Does it mean I need to re-build
> the database? Re-install?
>
> Thanks.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
L. Friedman                                    netllama@gmail.com
LlamaLand                       http://netllama.linux-sxs.org

Re: vaccum db fail

From
Tom Lane
Date:
Matthew Terenzio <webmaster@localnotion.com> writes:
> Trying vacuumdb eventuallydisplays this:
> ERROR:  catalog is missing 3 attribute(s) for relid 31457
> vacuumdb: vacuum  databasename failed

> There is another thread which states this is a corrupted systems
> catalog. Is this definitely the case? Does it mean I need to re-build
> the database? Re-install?

You've definitely got some problems in the pg_attribute catalog.
If you are lucky, reindexing pg_attribute will get you out of this.
Otherwise it's time to initdb and reload (or at least drop that one
database, recreate it, reload it).  I wouldn't trust half measures such
as dropping the one known-corrupt table, because the odds are that more
rows in pg_attribute got hit than just the ones reported in the first
failure.

            regards, tom lane