Re: Consistent segfault in complex query

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Kyle Samson <kysamson@tripadvisor.com>, "pgsql-hackers\@postgresql.org" <pgsql-hackers@postgresql.org>, Matthew Kelly <mkelly@tripadvisor.com>
Date: 2018-09-13T22:29:36Z
Lists: pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> 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 special
> proxy node that points back to the original estate?

I don't really think the amount of complexity that would add is something
to consider for a back-patchable fix.

> Well, the case of UPDATE ... SET foo = case when x then (select thing
> from big_cte) else (select thing from other_big_cte) end will be rather
> annoying if we end up forcing both initplans to execute.

Given that this bug has been there since the late bronze age and just now
got detected, I think that optimizing the fix for especially improbable
cases ought not be the first thing on our minds.  Let's just get it to
work reliably.

			regards, tom lane


Commits

  1. Fix failure with initplans used conditionally during EvalPlanQual rechecks.