Peter Neish <peter@austehc.unimelb.edu.au> writes:
> Tom Lane wrote:
>> Oh, that's interesting. Are there entries in pg_attribute for these
>> tables? Look for attrelid = 37894096 or 37894098. What PG version
>> is this exactly?
> Yes, 32 entries.
Wow, that's the first case I've heard of where whole tables were left
around with no matching schema. You'll probably find you have to drop
both the pg_class and pg_type rows before pg_dump will work --- AFAIR
you shouldn't have to clean out pg_attribute.
Since it's hard to tell exactly what's going on here, I'd suggest a
pg_dumpall/initdb/reload sequence to be sure there isn't any other
undetected corruption. Be sure to check that the dump contains
everything you expect though.
> Its runnign PG Version 7.4.7
An update would be a good idea --- the 7.4 branch is up to 7.4.14,
and we didn't make those patch releases just because we had nothing
else to do. It seems at least possible that this problem might be
explained by this 7.4.8 bug fix:
2005-05-07 17:33 tgl
* src/backend/: access/heap/hio.c, access/nbtree/nbtpage.c,
access/nbtree/nbtree.c, commands/vacuumlazy.c (REL7_4_STABLE):
Repair very-low-probability race condition between relation
extension and VACUUM: in the interval between adding a new page to
the relation and formatting it, it was possible for VACUUM to come
along and decide it should format the page too. Though not harmful
in itself, this would cause data loss if a third transaction were
able to insert tuples into the vacuumed page before the original
extender got control back.
The connection is that if this bug had resulted in loss of pg_depend
rows relating these two tables to their schema, then it would have been
possible to drop the schema without the tables being removed.
regards, tom lane