Re: pg_dumpall failing from possible corrupted shared memory

> > > 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.