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
-
Fix failure with initplans used conditionally during EvalPlanQual rechecks.
- f13e2d1cec9b 11.0 landed
- 9b14bbd52c8c 9.5.15 landed
- 99cbbbbd1ddd 10.6 landed
- 8494755109e9 9.4.20 landed
- 591d0ac8858c 9.3.25 landed
- 2a97a0ad34da 9.6.11 landed
- 1f4a920b7309 12.0 landed