| From: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
|---|---|
| To: | "'Heikki Linnakangas'" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, <armando(dot)miraglia(at)stud-inf(dot)unibz(dot)it> |
| Cc: | <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #6698: sub-query with join producing out of memory in where clause |
| Date: | 2012-06-20 06:33:47 |
| Message-ID: | 003801cd4eae$a63e01d0$f2ba0570$@kapila@huawei.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> I'm not sure what the correct fix is. I suppose we could pfree() the old
> value before overwriting it, but I'm not sure if that's safe, or if
> there might still be references to the old value somewhere in the executor.
It will resolve the current problem but I am also not sure whether it can create
any other problem because in this function most of the work is done in per-query memory context.
One thing if we can clarify that why per-tuple memory context is not sufficient for this value
than it can be easy to conclude on solution for this problem.
Another thing I have noticed is that in function ExecScanSubPlan, the similar work is not done in
Per-query memory context, I am not sure if it is of any relevance for the problem you mentioned.
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | rikard.pavelic | 2012-06-20 15:53:37 | BUG #6701: IS NOT NULL doesn't work on complex composites |
| Previous Message | msrbugzilla | 2012-06-20 05:53:14 | BUG #6700: Potential Bug in numeric.c |