> Matthew <matt(at)ctlno(dot)com> writes:
> > [ a tale of woe ]
> It looks like dropping and rebuilding *all* the indexes on your history
> table would be a good move (possibly with a vacuum of the table while
> the indexes are removed). You might want to do a COPY out to try to
> save the table data before the vacuum, in case there is corruption in
> the table as well as the indexes.
> Before you do all that, though, how big is the database? Would you be
> able/willing to tar up the whole $PGDATA tree and let some of us analyze
> regards, tom lane
I am going to tar up the $PGDATA directory so I have a backup of it
in case of bigger problems. I will send you a copy if you like but I have
already done some of the things you suggested but not all of them. The
database in question is (cms) 450 Meg, but we have a lot of databases in the
PGDATA directory, so the whole PGDATA directory totals to 3.1G. I don't
know if you want the whole thing or not. Let me know.
I dropped all the indexes on the history table did a vacuum then
recreated the index and vacuumed that table. That went fine, when I tried
to vacuum the entire database it hung on the cases table. I tried
reindexing that to no avail, and then tried dropping the index it appeared
to be hanging on then vacuuming and I got a different error, something about
memory being exhausted, which should not be the case, I don't have the exact
error in front of me any more :-( .
I'm still trying to get things back up and running. I believe I
have a successful pg_dump of the data in the cms database so I am going to
try to drop the cms database and restore from the dump. Unless you think
this is a bad idea.
Thank you very much for you help.
pgsql-hackers by date
|Next:||From: bpalmer||Date: 2001-03-23 17:38:16|
|Subject: Re: Re: Call for platforms|
|Previous:||From: Zeugswetter Andreas SB||Date: 2001-03-23 17:10:23|
|Subject: AW: AW: Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c |