Skip site navigation (1) Skip section navigation (2)

pgsql: Fix an old bug in after-trigger handling: AfterTriggerEndQuery

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix an old bug in after-trigger handling: AfterTriggerEndQuery
Date: 2008-10-25 03:32:44
Message-ID: 20081025033244.F13B57545A4@cvs.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committers
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_3_STABLE

Modified Files:
--------------
    pgsql/src/backend/commands:
        trigger.c (r1.227 -> r1.227.2.1)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/trigger.c?r1=1.227&r2=1.227.2.1)

pgsql-committers by date

Next:From: Tom LaneDate: 2008-10-25 03:32:52
Subject: pgsql: Fix an old bug in after-trigger handling: AfterTriggerEndQuery
Previous:From: Tom LaneDate: 2008-10-24 23:42:35
Subject: pgsql: Reduce the memory footprint of large pending-trigger-event lists,

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group