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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

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|refobjs ubid|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



---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly