Tom Lane wrote:
> After studying this awhile, I've concluded that neither of those
> ideas leads to a fix simple enough that I'd be comfortable with
> back-patching it. What seems like the best answer is to not pass
> delete_ok = true to afterTriggerInvokeEvents in AfterTriggerEndQuery.
> Then, a
I wrote:
> While fooling with the transition-tables bug, I noticed a problem
> in trigger.c that has been there a very long time.
> ...
> I think possibly the best solution is to change the query_stack
> data structure enough so that pre-existing entries don't get
> moved during an enlargement. Or
While fooling with the transition-tables bug, I noticed a problem
in trigger.c that has been there a very long time. AfterTriggerEndQuery
correctly notes
* ... Be careful here: firing a
* trigger could result in query_stack being repalloc'd, so we can't save
* its address across af