Re: [HACKERS] crash in plancache with subtransactions

2010-11-01 Thread Jim Nasby
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

Re: [HACKERS] crash in plancache with subtransactions

2010-11-01 Thread Tom Lane
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-29 Thread Alvaro Herrera
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-29 Thread Tom Lane
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-29 Thread Alvaro Herrera
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-27 Thread Tom Lane
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-26 Thread Tom Lane
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-22 Thread Tom Lane
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

[HACKERS] crash in plancache with subtransactions

2010-10-21 Thread Alvaro Herrera
Hi, 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. It was reported in 8.4, but I can

Re: [HACKERS] crash in plancache with subtransactions

2010-10-21 Thread Tom Lane
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-21 Thread Alvaro Herrera
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-21 Thread Alvaro Herrera
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-21 Thread Tom Lane
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

Re: [HACKERS] crash in plancache with subtransactions

2010-10-21 Thread Heikki Linnakangas
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,