vaccum db fail

Started by Matthew Terenzioover 21 years ago3 messagesgeneral
Jump to latest
#1Matthew Terenzio
webmaster@localnotion.com

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.

#2Lonni J Friedman
netllama@gmail.com
In reply to: Matthew Terenzio (#1)
Re: vaccum db fail

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

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Matthew Terenzio (#1)
Re: vaccum db fail

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