Andrew Gierth writes:
> If it helps, here is a patch that adds isolation tests to
> eval-plan-qual.spec for two test cases (one with CTE, one without).
> I've verified that these reproduce the crash, and that they run
> successfully with your patch. I can't currently see any more specific
> code p
> "Tom" == Tom Lane writes:
>> Your other idea of forcing initPlan parameters to be evaluated
>> before we enter the EPQ execution environment is probably more
>> workable.
Tom> Concretely, the attached seems to be enough to fix it (though I
Tom> only tried the simplest case you posted)
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Don't think that's going to work; the EPQ environment doesn't have
> Tom> any way to know that an execPlan link is pointing to something in
> Tom> a different estate.
> But can't such a way be created? e.g. by pointing execPlan to a spe
I wrote:
> Your other idea of forcing initPlan parameters to be evaluated before we
> enter the EPQ execution environment is probably more workable.
Concretely, the attached seems to be enough to fix it (though I only
tried the simplest case you posted).
I don't find anything to love about ExecEv
> "Tom" == Tom Lane writes:
>> What I'm wondering is whether the param in the copied estate
>> shouldn't rather be just a proxy for the one in the original estate
>> - if we need to evaluate it, then do so in the original estate,
>> store the value there, and copy the value back into the
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The second of those; what we need is for any referenced InitPlans
> Tom> to be executed afresh under EPQ rules. (I'm not entirely sure that
> Tom> an InitPlan could need to see different input tuples under EPQ
> Tom> than it'd see other
> "Tom" == Tom Lane writes:
>> So I can see exactly where the problem is, but I'm not sure what the
>> solution should be.
>> EvalPlanQualStart copies the param_exec value list explicitly _not_
>> including the execPlan link, which obviously isn't going to work if
>> the value has not b
Andrew Gierth writes:
> So I can see exactly where the problem is, but I'm not sure what the
> solution should be.
> EvalPlanQualStart copies the param_exec value list explicitly _not_
> including the execPlan link, which obviously isn't going to work if the
> value has not been computed yet. Sho
> "Andrew" == Andrew Gierth writes:
Andrew> Simpler testcase, removing the CTE, so this is clearly just
Andrew> about InitPlan:
So I can see exactly where the problem is, but I'm not sure what the
solution should be.
EvalPlanQualStart copies the param_exec value list explicitly _not_
incl
> "Andrew" == Andrew Gierth writes:
Andrew> Going to see if this can be narrowed down further.
Simpler testcase, removing the CTE, so this is clearly just about
InitPlan:
create table mytable (flag boolean default false, foo integer);
insert into mytable default values;
session B:
begin
> "Andrew" == Andrew Gierth writes:
Andrew> Bingo - I have a test case, which I'll post in a sec after
Andrew> testing it on other versions.
OK, not only does it break in latest 9.3 stable, it also breaks in
current master.
This is the testcase:
create table mytable (id integer, foo text
> "Andrew" == Andrew Gierth writes:
> "Kyle" == Kyle Samson writes:
Kyle> This is on a 9.3.19 server and we saw no
Kyle> mention of a fix in the release notes since this version and we
Kyle> do not know if it affects later major releases as well.
Andrew> There's a relevant commit fr
> "Andrew" == Andrew Gierth writes:
Tom> The reason this seems possibly different is that we're apparently
Tom> returning wrong data out of the sub-select (a zero Datum value,
Tom> but not marked isnull --- if it were, arraycontains wouldn't be
Tom> reached). The previously fixed bug woul
> "Tom" == Tom Lane writes:
>> There's a relevant commit from Feb this year (ea6d67cf8)
>> specifically referring to the case of CTEs inside subplans inside
>> EvalPlanQual, which is exactly the scenario you have in your query.
>> So you need to try this in 9.3.22 or later (ideally 9.3.24
Andrew Gierth writes:
> "Kyle" == Kyle Samson writes:
> Kyle> We encountered a query that has been able to frequently segfault
> Kyle> one of our postgres instances under certain conditions which we
> Kyle> have not fully been able to isolate for reproduction. We were
> Kyle> able to get a co
> "Kyle" == Kyle Samson writes:
Kyle> Hello,
Kyle> We encountered a query that has been able to frequently segfault
Kyle> one of our postgres instances under certain conditions which we
Kyle> have not fully been able to isolate for reproduction. We were
Kyle> able to get a core dump out
16 matches
Mail list logo
