strk <s...@keybit.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).
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. The relation_open part of it seems
essential even so; you could likely crash the backend with that.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
