| From: | Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com> | 
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | possible memory leak with SRFs | 
| Date: | 2010-05-05 13:53:13 | 
| Message-ID: | i2za301bfd91005050653n3a081161rde58ed28c3f16a7c@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Hi,
I saw this behavior with latest GIT head:
create table xlarge(val numeric(19,0));
insert into xlarge values(generate_series(1,5));
The above generate series will return an int8 which will then be
casted to numeric (via int8_to_numericvar) before being inserted into
the table. I observed that the ExprContext memory associated with
econtext->ecxt_per_tuple_memory is slowly bloating up till the end of
the insert operation.
This becomes significant the moment we try to insert a significant
number of entries using this SRF. I can see the memory being consumed
by the PG backend slowly grow to a large percentage.
I see that the executor (take ExecResult as an example) does not reset
the expression context early if an SRF is churning out tuples. What
could be a good way to fix this?
Regards,
Nikhils
-- 
http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2010-05-05 13:58:13 | Re: max_standby_delay considered harmful | 
| Previous Message | Heikki Linnakangas | 2010-05-05 13:46:15 | Re: max_standby_delay considered harmful |