From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jdassen(at)cistron(dot)nl (J(dot)H(dot)M(dot) Dassen (Ray)) |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Re: PostgreSQL; Strange error |
Date: | 2001-03-20 17:52:48 |
Message-ID: | 11596.985110768@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
jdassen(at)cistron(dot)nl (J.H.M. Dassen (Ray)) writes:
> Bengt Mnsson <name(at)some(dot)site> wrote:
>> Warning: PostgreSQL query failed: FATAL 1: my bits moved right off the end
>> of the world! Recreate index pg_attribute_relid_attnum_index.
This is an internal "can't happen" failure condition, presumably arising
from some weird corner-case bug in btree index manipulation. We have seen
sporadic reports of this failure, mostly from people using lots of large
objects, but no one has yet provided a test case that allows the problem
to be reproduced from scratch. When I'm in an optimistic mood I think
that the bug might be fixed in 7.1, but it's hard to say for sure
because I've never seen this failure happen myself.
> Follow the suggestion given in the warning: recreate index
> pg_attribute_relid_attnum_index, presumably [*] using something like
> DROP INDEX pg_attribute_relid_attnum_index;
> CREATE UNIQUE INDEX pg_attribute_relid_attnum_index ON
> pg_attribute(attrelid,attnum);
I think that will probably crash and burn :-(. To reconstruct a broken
system index you need to use the REINDEX command. See the manual for
the proper procedure for using REINDEX on system indexes; it's a tad
arcane.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Frank | 2001-03-20 18:17:43 | Re: Backing up postgresql databases |
Previous Message | Josh Berkus | 2001-03-20 17:43:20 | Re: Categories and subcategories : more details |