> Robert Haas <[email protected]> writes: > > That rearrangement got done in v11, and I've now committed that patch > > after fixing a few typos that I found. Cautiously, woohoo, but let's > > see if anything breaks.
Yay! On Wed, Jan 28, 2026 at 6:41 PM Tom Lane <[email protected]> wrote: > skink's not happy: > > =2162940== VALGRINDERROR-BEGIN > ==2162940== Conditional jump or move depends on uninitialised value(s) > ==2162940== at 0x434D366: cost_material (costsize.c:2593) > ==2162940== by 0x436E7E9: materialize_finished_plan (createplan.c:6531) > ==2162940== by 0x4383054: standard_planner (planner.c:533) > ... > ==2162940== by 0x44CD09D: ProcessUtility (utility.c:525) > ==2162940== Uninitialised value was created by a stack allocation > ==2162940== at 0x436E76A: materialize_finished_plan (createplan.c:6506) > >From a quick look, I think that's a missing initialization of path->parallel_workers when cost_material gets called with the dummy path created in materialize_finished_plan. The indirect relationship between those functions doesn't seem great (i.e. anything that gets read in cost_material has to be initialized in materialize_finished_plan). What if we just zero initialize the dummy Path structure instead, like in the attached? Thanks, Lukas -- Lukas Fittl
fix-materialize_finished_plan-Ensure-dummy-matpath-is-fu.nocf
Description: Binary data
