Re: Consistent segfault in complex query
Andrew Gierth <andrew@tao11.riddles.org.uk>
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyle Samson <kysamson@tripadvisor.com>,
"pgsql-hackers\@postgresql.org" <pgsql-hackers@postgresql.org>,
Matthew Kelly <mkelly@tripadvisor.com>
Date: 2018-09-12T16:13:13Z
Lists: pgsql-hackers
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> 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 would have caused either Tom> multiple or missed returns of a valid CTE tuple. Andrew> I have some ideas as to why, and I'm poking at them in order to Andrew> create a test case (no luck yet, but I'll keep at it). Bingo - I have a test case, which I'll post in a sec after testing it on other versions. The key in this case is that the EPQ is the _first_ time the InitPlan is executed - you need a construct like this: case when flag then foo when foo @> (select ... from cte) then foo end such that flag is true on the initially visible row version (hence the initplan is not run yet), but false on the modified version (hence running the initplan during EPQ). -- Andrew (irc:RhodiumToad)
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