Peter Neish <peter@xxxxxxxxxxxxxxxxxxxxxx> 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
