From: | Ed Loehr <ELOEHR(at)austin(dot)rr(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [GENERAL] "FATAL 1: my bits moved right off the end of theworld!" |
Date: | 1999-12-01 15:35:21 |
Message-ID: | 38454038.9B953DFC@austin.rr.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >
> > > This is getting to be our favourite error message...
> > >
> > > It is caused by a corrupted B-Tree index. Drop and recreate that one.
> >
> > Thanks. Unfortunately, the lack of context to the error message makes it difficult
> > to identify which index is "that one." The message was last showing up during the
> > process of dropping/recreating a series of triggers and functions via "psql -f"
> > without any table inserts/updates.
>
> I have fixed 7.0 so it will show the index name.
It sounds like this B-tree index corruption happens often enough to gain fame. I am
curious as to what the full impact of this is on a production database. Would I be
correct in assuming are consequences are (1) an unusable index, resulting in (2)
inaccessible data, resulting in (3) an unusable database until the index is dropped and
recreated?
If the least drastic corrective solution is to drop and recreate the index, that leaves
me wondering:
1) Does anyone know what is causing the corrupted B-tree?
2) How difficult would it be to automate the process of index rebuilding at the
point the corruption is detected? How could that be done otherwise in an automated
fashion?
3) What are other people doing to deal with this?
Cheers.
Ed
From | Date | Subject | |
---|---|---|---|
Next Message | Soundar | 1999-12-01 15:49:41 | JDBC 2.0 |
Previous Message | kaiq | 1999-12-01 15:33:04 | Re: [GENERAL] Date & Time |