I wrote:
> The crash occurs because we queue a deferred trigger here ...
> when we are not inside any AfterTriggerBeginQuery/AfterTriggerEndQuery
> pair. Normally _SPI_pquery() would take care of that detail, but it's
> been specifically told not to by the RI trigger code (notice the
> fire_triggers=0 arguments). It is not immediately obvious that an
> RI trigger query could never cause AFTER triggers to be queued, so
> I think this is at least a latent bug, even if this particular symptom
> involves intentional misconfiguration of standard triggers.
After further study I've gone back to the let's-just-make-the-assert-an-elog
camp. The reason we have an issue is exactly that the cascade-delete
trigger assumes that it will never be deferred, which is how come it
can get away with telling SPI to not deal with any invoked AFTER triggers
immediately. There isn't any good reason to support deferring that
trigger, nor is there any way to get into the state short of clueless
superuser manipulation of the catalogs.
I did look at modifying AfterTriggerFireDeferred, but concluded that's
not a great solution on two grounds:
* there doesn't seem to be any way to do it without taking a noticeable
performance hit (in particular, an extra useless scan over the deferred
trigger queue to verify everything's been fired);
* the crash occurs all the way back to 8.0, and such a fix would be a
great deal more trouble to back-port.
So elog it is ...
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
