Ireneusz Pluta <ipluta@xxxxx> writes: > W dniu 2012-02-27 21:59, Tom Lane pisze: >> I'd do the latter I think. Keep in mind that there are probably also >> entries in pg_depend linking the tables to the schemas. If your goal is >> only to get to a clean dumpable state and then dump and reload the >> database, you probably don't need to worry about fixing pg_depend. >> However, if you intend to keep on using the database without a reload, >> it'd be prudent to make sure pg_depend is straightened out as well. > I found rows of missing namespace oid in pg_depend.refobjid. I understand that I update them to oid > of a newly created empty schema? Right. > But, as in the menatime I played with the case separately on a test database, I found also pg_type > entries need fixing. I was not aware of pg_depend, but found that after only tweaking both pg_class, > and pg_type the database got dumpable. Hm. We've seen occasional reports of this sort of behavior (that is, DROP of a schema failing to cascade to all the contained objects) but never been able to reproduce it. If you do see it happen again, and can work out a scenario that causes it (even only intermittently) we'd love to have a test case. 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. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general