Re: pg_class.relnamespace NOT IN pg_namespace.oid
От | Tom Lane |
---|---|
Тема | Re: pg_class.relnamespace NOT IN pg_namespace.oid |
Дата | |
Msg-id | 21687.1330386100@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_class.relnamespace NOT IN pg_namespace.oid (Ireneusz Pluta <ipluta@wp.pl>) |
Список | pgsql-general |
Ireneusz Pluta <ipluta@wp.pl> writes: > W dniu 2012-02-27 23:57, Tom Lane pisze: >> One possible theory for cascaded drops to fail like that is that the indexes on pg_depend are >> corrupt, so you might want to consider REINDEXing that catalog, just in case. > so before reindexing it would be worth veryfing the theory and check indexes for corruption in their > current state. But I am not sure if I know how to perform these particular checks. The only ones I > could invent myself, pretty naively right now, are as follows, but I am not sure if they give the > information wee look for: It's difficult to prove anything after the fact. You could check whether select * from pg_depend where refclassid = 2615 and refobjid = <missing schema's OID>; finds entries for all the objects that currently refer to the missing schema. But there are various strange rules (eg, I think we don't bother to make a separate entry for a table's pg_type row), and more to the point what happens today doesn't necessarily prove much about what happened when the DROP failed. Addition/deletion of other index entries could mask a failure condition that occurred before. regards, tom lane
В списке pgsql-general по дате отправления: