Thread: IndexSupportInitialize Error
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!"
"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
The most powerful anti-spam software available.
http://mail.spaminspector.com
"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