Thread: IndexSupportInitialize Error

IndexSupportInitialize Error

From
"Bryan Bullard"
Date:
Hi Everyone.
 
Last week our server's system disk broke causing the server to die a hard death.  We run Postgres on another disk and the binaries and associated cluster seemed to have survived.  However when I try to connect (psql, dumpdb, dumpall) to any of the databases I get the following error:
 
        FATAL 1:  IndexSupportInitialize: bogus pg_index tuple
 
We are running RH 7.3, Postgres 7.2.1 (We were in the process of upgrading our databases - this was the last).  A quick search of the archives doesn't uncover much in regard to this problem.  Any ideas our there?  Unfortunately we don't have a usable backup for the database in question so any assistance with this would be great.
 
Thanks
 
-bryan
 
 
 
---------------------------------------------------------------------
"Are you still wasting your time with spam?...
There is a solution!"
 
Protected by GIANT Company's Spam Inspector
The most powerful anti-spam software available.
http://mail.spaminspector.com
 
 

Re: IndexSupportInitialize Error

From
Tom Lane
Date:
"Bryan Bullard" <bbullard@friendlymatrix.com> writes:
> Last week our server's system disk broke causing the server to die a hard d=
> eath.  We run Postgres on another disk and the binaries and associated clus=
> ter seemed to have survived.  However when I try to connect (psql, dumpdb, =
> dumpall) to any of the databases I get the following error:
>         FATAL 1:  IndexSupportInitialize: bogus pg_index tuple
> We are running RH 7.3, Postgres 7.2.1 (We were in the process of upgrading =
> our databases - this was the last).  A quick search of the archives doesn't=
>  uncover much in regard to this problem.  Any ideas our there?

*Any* of the databases?  Since pg_index isn't shared it's difficult to
imagine a failure scenario that would wipe out all the databases in an
installation in this same way.

The error itself suggests that you've got a zeroed-out row in pg_index.
You could possibly recover by manually dropping the index in question,
if it's not a critical index.  What I'd try doing is starting a
standalone backend with the -P switch (ignore system indexes); if that
will let you in, then you'd be able to look through pg_index to try to
determine what's clobbered.

            regards, tom lane