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
Hello,
We encountered a query that has been able to frequently segfault one of our
postgres instances under certain conditions which we have not fully been able
to isolate for reproduction. We were able to get a core dump out of one of the
crashes and have poked at it, but we believe the answer
17 matches
Mail list logo
