Added to TODO: > o Fix memory leak from exceptions > > http://archives.postgresql.org/pgsql-performance/2006-06/msg0$ --------------------------------------------------------------------------- Tom Lane wrote: > "jody brownell" <jody.brownell@xxxxxxxxxx> writes: > > BEGIN > > INSERT into attacker_target_link (attacker_id, target_id) values (p_attacker, v_target); > > v_returns_size := v_returns_size + 1; > > v_returns[v_returns_size] := v_target; > > > EXCEPTION WHEN unique_violation THEN > > -- do nothing... app cache may be out of date. > > END; > > Hmm. There is a known problem that plpgsql leaks some memory when > catching an exception: > http://archives.postgresql.org/pgsql-hackers/2006-02/msg00885.php > > So if your problem case involves a whole lot of duplicates then that > could explain the initial bloat. However, AFAIK that leakage is in > a transaction-local memory context, so the space ought to be freed at > transaction end. And Linux's malloc does know about giving space back > to the kernel (unlike some platforms). So I'm not sure why you're > seeing persistent bloat. > > Can you rewrite the function to not use an EXCEPTION block (perhaps > a separate SELECT probe for each row --- note this won't be reliable > if there are concurrent processes making insertions)? If so, does > that fix the problem? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
