> However, EvalPlanQual still leaks more memory than suits me ---
> auxiliary memory allocated by the plan nodes is not recovered.
> I think the correct way to implement it would be to create a new
> memory context for each level of EvalPlanQual execution and use
> that context as the "per-query c
> > How subselects run queries again and again?
>
> They don't end and restart them; they just rescan them. If we had
Thanks for recollection.
> this substitute-a-new-tuple hack integrated into the Param mechanism,
> then EvalPlanQual could use ExecReScan too, but at the moment no...
I see.
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
>> However, EvalPlanQual still leaks more memory than suits me ---
>> auxiliary memory allocated by the plan nodes is not recovered.
> Isn't plan shutdown supposed to free memory?
Yeah, but it leaks all over the place; none of the plan node types
bothe
I wrote:
> The direct cause of the problem is that EvalPlanQual isn't completely
> initializing the estate that it sets up for re-evaluating the plan.
> In particular it's not filling in es_result_relations and
> es_num_result_relations, which need to be set up if the top plan node
> is an Append.
"A.V.Shutko" <[EMAIL PROTECTED]> writes:
> Your server have a bug that sometimes cause coredumps.
> Tom Lane> What version of postgres?
> # ./postgres -V
> postgres (PostgreSQL) 7.1
Okay, I think I understand the scenario here. Are you using table
inheritance? I can produce a crash in the
"A.V.Shutko" <[EMAIL PROTECTED]> writes:
> Your server have a bug that sometimes cause coredumps.
What version of postgres? What is the query being processed?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'ki
Hello , mans
Your server have a bug that sometimes cause coredumps.
System:FreeBSD 4.2-20001127-STABLE
Compiler: gcc 2.95.2
Platform: x86 (PII-600)
Ram: 256 Mb
With server work only one program - IServerd, there is 10 parallel
processes that have db connection.
Here information
