Viatcheslav Kalinin <[EMAIL PROTECTED]> writes: > I've made two cases actually, simple one that I already mentioned about > in my previous mails and more complex one that I tried to make somewhat > close to our work case where I first encountered the problem in question.
As I said before, the only memory growth I see in the first one is the list of subcommitted child XIDs, which we really can't get rid of. The second one is having problems because of AFTER triggers fired for the foreign key constraints. That we can improve, as per the attached patch. regards, tom lane
Index: trigger.c =================================================================== RCS file: /cvsroot/pgsql/src/backend/commands/trigger.c,v retrieving revision 1.210.2.1 diff -c -r1.210.2.1 trigger.c *** trigger.c 25 Jan 2007 04:17:56 -0000 1.210.2.1 --- trigger.c 1 Jul 2007 17:26:52 -0000 *************** *** 2766,2771 **** --- 2766,2789 ---- afterTriggers->state_stack[my_level] = NULL; Assert(afterTriggers->query_depth == afterTriggers->depth_stack[my_level]); + /* + * It's entirely possible that the subxact created an event_cxt but + * there is not anything left in it (because all the triggers were + * fired at end-of-statement). If so, we should release the context + * to prevent memory leakage in a long sequence of subtransactions. + * We can detect whether there's anything of use in the context by + * seeing if anything was added to the global events list since + * subxact start. (This test doesn't catch every case where the + * context is deletable; for instance maybe the only additions were + * from a sub-sub-xact. But it handles the common case.) + */ + if (afterTriggers->cxt_stack[my_level] && + afterTriggers->events.tail == afterTriggers->events_stack[my_level].tail) + { + MemoryContextDelete(afterTriggers->cxt_stack[my_level]); + /* avoid double delete if abort later */ + afterTriggers->cxt_stack[my_level] = NULL; + } } else {
---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster