Обсуждение: Unable to drop index

Hi,

I have an error trying to drop an index using PostgreSQL 7.4.6 running
on Solaris 2.9.

The table on which the index was built is no longer present (it should
have been dropped by my application after being used), but it would
appear that the index was not dropped at the same time as the table:

drop index iext_41827440000_24 ;
ERROR:  could not open relation with OID 147483811

Looking in pg_class for an entry with this OID (147483811) returns 0
rows; an entry exists in pg_class for the index itself.

How can I safely remove the index?  The old copy of the index is
preventing the creation of a new table and associated index of the same
names.

Would manually deleting the records that relate to the index in pg_index
and pg_class be sufficient, or is that likely to do more harm than good?

Many thanks,

Oliver


--
Oliver Duke-Williams <o.w.duke-williams@leeds.ac.uk>
School of Geography University of Leeds

Oliver Duke-Williams <o.w.duke-williams@leeds.ac.uk> writes:
> The table on which the index was built is no longer present (it should
> have been dropped by my application after being used), but it would
> appear that the index was not dropped at the same time as the table:

That's fairly strange; it should be impossible, in fact, because of the
pg_depend mechanism.

> drop index iext_41827440000_24 ;
> ERROR:  could not open relation with OID 147483811

> Looking in pg_class for an entry with this OID (147483811) returns 0
> rows; an entry exists in pg_class for the index itself.

What is the OID of the index itself?  Are there any rows in pg_depend
matching either the index OID or 147483811 in either objid or refobjid?
How about pg_index (see indexrelid and indrelid respectively)?  How
about pg_attribute (see attrelid)?  Is the underlying file (named by
pg_class.relfilenode) still there?

> How can I safely remove the index?  The old copy of the index is
> preventing the creation of a new table and associated index of the same
> names.

You can probably just "rm" the underlying file and DELETE the pg_class
row plus any other rows you found above.  However I wonder what other
corruption may have occurred in whatever event produced this situation.
I'm thinking you might have lost a whole page of pg_class, for example.
It'd likely be a good idea to see if you can pg_dump and reload the
database.

            regards, tom lane

Tom Lane wrote:
>
>>The table on which the index was built is no longer present (it should
>>have been dropped by my application after being used), but it would
>>appear that the index was not dropped at the same time as the table:
>
>
> That's fairly strange; it should be impossible, in fact, because of the
> pg_depend mechanism.
>
>
>>drop index iext_41827440000_24 ;
>>ERROR:  could not open relation with OID 147483811
>
>
>>Looking in pg_class for an entry with this OID (147483811) returns 0
>>rows; an entry exists in pg_class for the index itself.
>
>
> What is the OID of the index itself?  Are there any rows in pg_depend
> matching either the index OID or 147483811 in either objid or refobjid?

The index has OID 149592817; there are two rows in pg_depend relating to
the index as a object dependent on the table:

zzwicid=# select * from pg_depend where objid =  149592817 or refobjid =
147483811;
classid|objid|objsubid|refclassid|refobjid|refobjsubid|deptype
1259|149592817|0|1259|147483811|1|a
1259|149592817|0|1259|147483811|3|a

The index was on two fields, so this is as expected.

> How about pg_index (see indexrelid and indrelid respectively)?

Yes

>  How about pg_attribute (see attrelid)?

Yes - two rows corresponding to the index.

> Is the underlying file (named by pg_class.relfilenode) still there?

Yes
>
>>How can I safely remove the index?  The old copy of the index is
>>preventing the creation of a new table and associated index of the same
>>names.
>
>
> You can probably just "rm" the underlying file and DELETE the pg_class
> row plus any other rows you found above.  However I wonder what other
> corruption may have occurred in whatever event produced this situation.
> I'm thinking you might have lost a whole page of pg_class, for example.
> It'd likely be a good idea to see if you can pg_dump and reload the
> database.

OK - will dump / reload the database and then try dropping the index
manually.

Thanks for your reply,

Oliver