Re: pg_plan_advice

> Robert Haas <robertmhaas(at)gmail(dot)com> 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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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