Skip site navigation (1) Skip section navigation (2)

Re: pg_class.relnamespace NOT IN pg_namespace.oid

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ireneusz Pluta <ipluta(at)wp(dot)pl>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_class.relnamespace NOT IN pg_namespace.oid
Date: 2012-02-27 23:41:40
Message-ID: 21687.1330386100@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-general
Ireneusz Pluta <ipluta(at)wp(dot)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

In response to

pgsql-general by date

Next:From: Jameison MartinDate: 2012-02-28 00:30:56
Subject: xlog corruption
Previous:From: Ireneusz PlutaDate: 2012-02-27 23:24:37
Subject: Re: pg_class.relnamespace NOT IN pg_namespace.oid

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group