Thread: Re: PostgreSQL; Strange error

Bengt Månsson <name@some.site> wrote:
>I use RH7, Apache, PHP4 and PostgreSQL

Your problem is a RDBMS problem, not a WWW server one. The PostgreSQL
mailing lists (see http://www.postgresql.org/users-lounge/index.html) are a
better place to ask.

>Warning: PostgreSQL query failed: FATAL 1: my bits moved right off the end
>of the world! Recreate index pg_attribute_relid_attnum_index.

>I don't understand any of this. Never heard of that index.

It starts with "pg_", so it's Postgres' meta-data (internal administration).

>What does it mean?

Apparently one of Postgres' internal indexes got corrupted.

> What can I do?

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);

(as database user 'postgres').

HTH,
Ray

[*] I'm just guessing from '\d pg_attribute_relid_attnum_index' and '\d
pg_attribute' - back up your database (using "pg_dump") before trying this.
--
Think of computer security like powertools. The day you think you are
totally safe is the day you end up hurt.
    Alan Cox

jdassen@cistron.nl (J.H.M. Dassen (Ray)) writes:
> Bengt M�nsson <name@some.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