Fix extremely nasty little bug observed when a sub-SELECT appears in
WHERE in a place where it can be part of a nestloop inner indexqual. As the code stood, it put the same physical sub-Plan node into both indxqual and indxqualorig of the IndexScan plan node. That confused later processing in the optimizer (which expected that tracing the subPlan list would visit each subplan node exactly once), and would probably have blown up in the executor if the planner hadn't choked first. Fix by making the 'fixed' indexqual be a complete deep copy of the original indexqual, rather than trying to share nodes below the topmost operator node. This had further ramifications though, because we were making the aforesaid list of sub-Plan nodes during SS_process_sublinks which is run before construction of the 'fixed' indexqual, meaning that the copy of the sub-Plan didn't show up in that list. Fix by rearranging logic so that the sub-Plan list is built by the final set_plan_references pass, not in SS_process_sublinks. This may sound like a mess, but it's actually a good deal cleaner now than it was before, because we are no longer dependent on the assumption that planning will never make a copy of a sub-Plan node.
Showing
Please register or sign in to comment