Per-tuple memory leak in 9.0

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Per-tuple memory leak in 9.0
Date: 2010-08-18 17:29:00
Message-ID: AANLkTi=nHa6_WU3FJ1t0oT=--4HOhLxiJ8ot+kQarz-V@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

While testing triggers, I came across the following memory leak.
Here's a simple test case:

CREATE TABLE foo(a int);

CREATE OR REPLACE FUNCTION trig_fn() RETURNS trigger AS
$$
BEGIN
RETURN NEW;
END;
$$
LANGUAGE plpgsql;

CREATE TRIGGER ins_trig BEFORE INSERT ON foo
FOR EACH ROW EXECUTE PROCEDURE trig_fn();

INSERT INTO foo SELECT g
FROM generate_series(1, 5000000) AS g;

Memory usage goes up by around 100 bytes per row for the duration of the query.

The problem is that the trigger code assumes that anything it
allocates in the per-tuple memory context will be freed per-tuple
processed, which used to be the case because the loop in ExecutePlan()
calls ResetPerTupleExprContext() once each time round the loop, and
that used to correspond to once per tuple.

However, with the refactoring of that code out to nodeModifyTable.c,
this is no longer the case because the ModifyTable node processes all
the tuples from the subquery before returning, so I guess that the
loop in ExecModifyTable() needs to call ResetPerTupleExprContext()
each time round.

Regards,
Dean

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Robert Haas 2010-08-18 17:30:51 Re: BUG #5623: xml2 and uuid-ossp contribs fail to compile
Previous Message Stanisluv Platonov 2010-08-18 17:19:32 BUG #5625: PostgreSQL fail to install files in data folder.

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-08-18 17:31:18 Re: git: uh-oh
Previous Message Robert Haas 2010-08-18 17:10:19 Re: git: uh-oh