Re: pg_plan_advice - Mailing list pgsql-hackers

From Richard Guo
Subject Re: pg_plan_advice
Date
Msg-id CAMbWs4--NuEUFE_xTo991TRXaZryE29jarJPDnVxoaQOYdt7tA@mail.gmail.com
Whole thread Raw
In response to Re: pg_plan_advice  (Lukas Fittl <lukas@fittl.com>)
Responses Re: pg_plan_advice
List pgsql-hackers
> On Wed, Jan 28, 2026 at 6:41 PM Tom Lane <tgl@sss.pgh.pa.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)

FWIW, the following related code in reparameterize_path() seems unsafe
to me:

    spath = reparameterize_path(root, spath,
                                required_outer,
                                loop_count);
    enabled =
        (mpath->path.disabled_nodes <= spath->disabled_nodes);
    if (spath == NULL)
        return NULL;
    return (Path *) create_material_path(rel, spath, enabled);

I think we should access spath->disabled_nodes until after we have
verified that spath is not NULL.

Also, it's not quite clear to me why create_material_path (and
cost_material) requires the "enabled" parameter.  I couldn't find any
comments on this, so it might be worth adding some comments here.

- Richard



pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: ATPrepCmd: cleanup unreachable AT_AddIndexConstraint handling
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: logical apply worker's lock waits in subscriber can stall checkpointer in publisher