From: | Ireneusz Pluta <ipluta(at)wp(dot)pl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_class.relnamespace NOT IN pg_namespace.oid |
Date: | 2012-02-28 17:30:37 |
Message-ID: | 4F4D0F3D.2060002@wp.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
W dniu 2012-02-27 23:57, Tom Lane pisze:
> 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.
I think we could try to play here a bit and arrange some possible scenarios with (abnormal)
execution of the the script which creates/drops the schemas and see what happens.
Could you help me find what is the particular order of cascaded table drops? Is it the exact same
order as indicated in the list following the NOTICE: drop cascades to xx other objects? I can see
that logged order is the same as the order of table creation - so order by oid? If yes then the
orphaned two tables of my case are the very last ones expected to be dropped.
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Atkins | 2012-02-28 17:34:08 | Re: what Linux to run |
Previous Message | Adrian Klaver | 2012-02-28 17:17:38 | Re: Having a problem with RoR-3.1.1 and Pg-9.1 |