Thread: pgsql: Fix an old bug in after-trigger handling: AfterTriggerEndQuery
pgsql: Fix an old bug in after-trigger handling: AfterTriggerEndQuery
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message: ----------- Fix an old bug in after-trigger handling: AfterTriggerEndQuery took the address of afterTriggers->query_stack[afterTriggers->query_depth] and hung onto it through all its firings of triggers. However, if a trigger causes sufficiently many nested query executions, query_stack will get repalloc'd bigger, leaving AfterTriggerEndQuery --- and hence afterTriggerInvokeEvents --- using a stale pointer. So far as I can find, the only consequence of this error is to stomp on a couple of words of already-freed memory; which would lead to a failure only if that chunk had already gotten re-allocated for something else. So it's hard to exhibit a simple failure case, but this is surely a bug. I noticed this while working on my recent patch to reduce pending-trigger space usage. The present patch is mighty ugly, because it requires making afterTriggerInvokeEvents know about all the possible event lists it might get called on. Fortunately, this is only needed in back branches because CVS HEAD avoids the problem in a different way: afterTriggerInvokeEvents only touches the passed AfterTriggerEventList pointer once at startup. Back branches are stable enough that wiring in knowledge of all possible call usages doesn't seem like a killer problem. Back-patch to 8.0. 7.4's trigger code is completely different and doesn't seem to have the problem (it doesn't even use repalloc). Tags: ---- REL8_2_STABLE Modified Files: -------------- pgsql/src/backend/commands: trigger.c (r1.210.2.5 -> r1.210.2.6) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/trigger.c?r1=1.210.2.5&r2=1.210.2.6)