> > > but before you do that, I'd urge
> > > you to try to get as much info as you can about the nature of the
> > > catalog corruption. If there's a bug here, as opposed to random
> > > cosmic-ray damage, we can't fix it without more info.
>
> I eliminated the non-offending index with this query:
>
> select pg_get_indexdef(indexrelid)
> from pg_index
> where indexrelid <> 604251 -- this is the index with the problem
> order by indexrelid;
>
> How do I go about determining if the crash i caused by faulty hardware or a
> possible bug?
I finially narrowed to search down to the offending column and rows that causes
the crash. The
following two queries work as long as I don't combine indexname='index_daily'
and indexdef.
select *
from pg_indexes
where indexname <> 'index_daily';
....
returns all rows execpt the affected row
....
select schemaname,
tablename,
indexname,
tablespace --returns all columns except the affected column
from pg_indexes
where indexname = 'index_daily';
schemaname | tablename | indexname | tablespace
------------+-----------+-------------+------------
public | process | index_daily |
and finially, to show that it crashes:
select indexdef
from pg_indexes
where indexname = 'index_daily';
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
Regards,
Richard Broersma Jr.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
