From: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Petr Jelinek <petr(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Column/type dependency recording inconsistencies |
Date: | 2014-11-11 23:10:48 |
Message-ID: | 54629778.1030708@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/11/14 21:47, Tom Lane wrote:
> I wrote:
>> ... Also, I find physically removing an entry fairly ugly and
>> possibly unsafe, since it's not clear what outer recursion levels might be
>> assuming about the contents of the array -- and that certainly won't work
>> for the stack case. What seems better is to invent another flag bit
>> to indicate that we no longer need to physically delete this subobject
>> because we've discovered the whole object will be deleted. Then we
>> can just skip it during the execution phase.
>
> On further reflection, neither of those approaches is really a good idea.
> With either implementation, skipping the DROP COLUMN step would mean that
> we're letting the DROP TYPE happen before we drop a table containing a
> live column of that type. While that failed to fail in this particular
> example, it sounds like a really bad idea --- any number of things, such
> as event triggers, could well blow up when abused like that. The lack of
> prior reports means that this is a very rare case, so rather than trying
> to "optimize" it, I think we should just let the drops happen in the
> scheduled order. All that we need is to make sure that the column gets
> marked with flags indicating that dropping is allowed. Accordingly, the
> attached patch should do it.
>
Yup, this patch seems to be much better and safer fix.
I can confirm that it works fine with both the test-case and my original
upgrade script. Thanks!
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-11-11 23:49:50 | Re: Minor problem with comment added by 5ea86e |
Previous Message | Jim Nasby | 2014-11-11 23:08:32 | Re: git.postgresql.org not finding a commit |