Jim Nasby writes:
> (looking at original case)... the original bug wasn't actually
> recursive.
No, there are two different cases being dealt with here. If the first
call of an expression results in an error, and then we come back and try
to re-use the expression state tree, we can have trouble
On Oct 29, 2010, at 10:54 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of mié oct 27 18:18:06 -0300 2010:
>>> I spent quite a bit of time trying to deal with the memory-leakage
>>> problem without adding still more bookkeeping overhead. It wasn't
>>> looking go
Excerpts from Tom Lane's message of vie oct 29 12:54:52 -0300 2010:
> Alvaro Herrera writes:
> > I tried the original test cases that were handed to me (quite different
> > from what I submitted here) and they are fixed also. Thanks.
>
> It'd be interesting to know if there's any noticeable slo
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié oct 27 18:18:06 -0300 2010:
>> I spent quite a bit of time trying to deal with the memory-leakage
>> problem without adding still more bookkeeping overhead. It wasn't
>> looking good, and then I had a sudden insight: if we see that
Excerpts from Tom Lane's message of mié oct 27 18:18:06 -0300 2010:
> I wrote:
> >> Heikki Linnakangas writes:
> >>> One simple idea is to keep a flag along with the executor state to
> >>> indicate that the executor state is currently in use. Set it just before
> >>> calling ExecEvalExpr, and r
I wrote:
>> Heikki Linnakangas writes:
>>> One simple idea is to keep a flag along with the executor state to
>>> indicate that the executor state is currently in use. Set it just before
>>> calling ExecEvalExpr, and reset afterwards. If the flag is already set
>>> in the beginning of exec_eval
I wrote:
> Heikki Linnakangas writes:
>> One simple idea is to keep a flag along with the executor state to
>> indicate that the executor state is currently in use. Set it just before
>> calling ExecEvalExpr, and reset afterwards. If the flag is already set
>> in the beginning of exec_eval_simp
Heikki Linnakangas writes:
> On 22.10.2010 06:10, Tom Lane wrote:
>> (But on the third
>> hand, what are we gonna do for back-patching to versions without the
>> plancache?)
> One simple idea is to keep a flag along with the executor state to
> indicate that the executor state is currently in us
On 22.10.2010 06:10, Tom Lane wrote:
Right at the moment I'm not seeing any way that the present
exec_eval_simple_expr approach can be fixed to work safely in the
presence of recursion. What I think we might have to do is give up
on the idea of caching execution state trees across calls, instead
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue oct 21 19:36:07 -0300 2010:
>> I don't believe that it's plancache's fault; the real problem is that
>> plpgsql is keeping "simple expression" execution trees around longer
>> than it should. Your patch masks the problem by forcing
Excerpts from Tom Lane's message of jue oct 21 19:36:07 -0300 2010:
> I'm not immediately sure why plpgsql_subxact_cb is failing to clean up
> correctly in this example, but that seems to be where to look.
I think the reason is that one econtext is pushed for function
execution, and another one f
Excerpts from Tom Lane's message of jue oct 21 19:36:07 -0300 2010:
> Alvaro Herrera writes:
> > A customer was hitting some misbehavior in one of their internal tests and
> > I tracked it down to plancache not behaving properly with
> > subtransactions: in particular, a plan is not being marked "
Alvaro Herrera writes:
> A customer was hitting some misbehavior in one of their internal tests and
> I tracked it down to plancache not behaving properly with
> subtransactions: in particular, a plan is not being marked "dead" when
> the subtransaction on which it is planned rolls back.
I don't
13 matches
Mail list logo
