On Oct 29, 2010, at 10:54 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Jim Nasby j...@nasby.net 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
Excerpts from Tom Lane's message of mié oct 27 18:18:06 -0300 2010:
I wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
Excerpts from Tom Lane's message of vie oct 29 12:54:52 -0300 2010:
Alvaro Herrera alvhe...@commandprompt.com 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
I wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
I wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Alvaro Herrera alvhe...@alvh.no-ip.org 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
Excerpts from Tom Lane's message of jue oct 21 19:36:07 -0300 2010:
Alvaro Herrera alvhe...@alvh.no-ip.org 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
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
Alvaro Herrera alvhe...@commandprompt.com 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
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,
13 matches
Mail list logo
