Re: BUG #6698: sub-query with join producing out of memory in where clause - Mailing list pgsql-bugs

From Amit Kapila
Subject Re: BUG #6698: sub-query with join producing out of memory in where clause
Date
Msg-id 003801cd4eae$a63e01d0$f2ba0570$@kapila@huawei.com
Whole thread Raw
In response to Re: BUG #6698: sub-query with join producing out of memory in where clause  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-bugs
> I'm not sure what the correct fix is. I suppose we could pfree() the old=
=20
> value before overwriting it, but I'm not sure if that's safe, or if=20
> there might still be references to the old value somewhere in the executo=
r.

It will resolve the current problem but I am also not sure whether it can c=
reate
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 suffic=
ient for this value
than it can be easy to conclude on solution for this problem.=20

Another thing I have noticed is that in function ExecScanSubPlan, the simil=
ar work is not done in
Per-query memory context, I am not sure if it is of any relevance for the p=
roblem you mentioned.


With Regards,
Amit Kapila.

pgsql-bugs by date:

Previous
From: Craig Ringer
Date:
Subject: Re: BUG #5823: launchd execution
Next
From: msrbugzilla@gmail.com
Date:
Subject: BUG #6700: Potential Bug in numeric.c