From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | strk <strk(at)keybit(dot)net>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DROP SCHEMA xxx CASCADE: ERROR: could not open relation with OID yyy |
Date: | 2011-02-10 05:37:06 |
Message-ID: | 20110210053706.GA8190@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 10, 2011 at 12:03:49AM -0500, Tom Lane wrote:
> strk <strk(at)keybit(dot)net> writes:
> > I've finally completed the debugging phase and have
> > a minimal self-contained testcase showing the problem.
> > It has to do with INITIALLY DEFERRED constraints.
>
> I looked into this and find that the issue is you're trying to drop a
> table that has unfired AFTER TRIGGER events pending. When they finally
> fire, they can't find the table anymore.
>
> I'm inclined to think that we should disallow that; or even more to the
> point, that it'd be a good thing to apply CheckTableNotInUse() when
> about to drop a table. If we disallow such cases for ALTER TABLE, then
> a fortiori we should do so for DROP TABLE.
>
> Aside from disallowing unfired trigger events, CheckTableNotInUse would
> disallow the table being actively relation_open'd by any operation.
> This seems like a real good thing anyway (imagine, eg, DROP TABLE
> executed from a trigger for that table).
+1. We even do it for TRUNCATE, so surely it's proper for DROP.
> It's possible that we could handle the unfired-trigger problem by
> marking the relevant events AFTER_TRIGGER_DONE, but I'm unconvinced that
> it's worth spending effort on.
Seems rare enough not to worry much about, particularly considering the SET
CONSTRAINTS escape hatch.
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2011-02-10 06:04:54 | Re: [COMMITTERS] pgsql: Update docs on building for Windows to accomodate current realit |
Previous Message | Tom Lane | 2011-02-10 05:03:49 | Re: DROP SCHEMA xxx CASCADE: ERROR: could not open relation with OID yyy |