Ireneusz Pluta <ipl...@wp.pl> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
