Mike Mascari wrote:
> > It is, because a corrupted index on a system table cannot be
> > corrected by drop/create, as a user defined index could be.
> >
> > I don't know why and when reindexdb disappeared, but that
> > script was a last resort for exactly the situation of a
> > corrupted system index. Let me take a look if this
> > functionality could easily be recreated.
>
> For what its worth, TRUNCATE TABLE already rebuilds indexes on TRUNCATE'd
> tables, so it shouldn't be that much of a leap, one would think.
Imagine a corrupted pg_attribute_attrelid_index. What would
it be good for to do a TRUNCATE TABLE pg_attribute? For god's
sake, it's not permitted.
I'm talking about corrupted system catalog indices! There's a
substantial difference for them. If only one is missing, you
might not be able to even connect to that database because
the backend wouldn't start up. The problem here is, that the
system catalog's partially reside in a shared memory cache
during the lifetime of a postmaster! And remember, one
postmaster can server many databases. There are REALLY
different semantics!
Please folks, it's nice if you succeded in recovering from a
corrupted index. But as long as it's name didn't start with
pg_, it's not what I'm talking about.
Maybe a directly issued index_build() from the bootstrap
interface might help. Will create another bootparser command
and give it a try.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #