Re: Memory leak in deferrable index constraints

On 31 January 2010 16:03, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com> writes:
>> Oops, my fault. The list returned by ExecInsertIndexTuples() needs to be
>> freed otherwise lots of lists (one per row) will build up and not be freed
>> until the end of the query. This actually accounts for even more memory
>> than the after-trigger event queue. Patch attached.
>
> It seems a bit unlikely that this would be the largest memory leak in
> that area.  Can you show a test case that demonstrates this is worth
> worrying about?
>

If I do

create table foo(a int unique deferrable initially deferred);
insert into foo (select * from generate_series(1, 10000000));
begin;
update foo set a=a+1;
set constraints all immediate;
commit;

and watch the backend memory usage during the UPDATE, it grows to
around 970MB and then falls back to 370MB as soon as the UPDATE
command finishes. During whole SET CONSTRAINTS trigger execution
it then remains constant at 370MB.

With this patch, it never grows beyond the 370MB occupied by the
after-triggers queue.

Regards,
Dean