On 2025/06/17 20:37, Ranier Vilela wrote:
> Em ter., 17 de jun. de 2025 às 06:09, Etsuro Fujita <etsuro.fujita@gmail.com <mailto:etsuro.fujita@gmail.com>>
escreveu:
>
> Hi,
>
> On Tue, Jun 17, 2025 at 2:38 PM Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>>
wrote:
> > adjust_foreign_grouping_path_cost(root, pathkeys,
> >
retrieved_rows,width,
> > -
fpextra->limit_tuples,
> > + fpextra ?
fpextra->limit_tuples: 0.0,
> >
&disabled_nodes,
> >
&startup_cost,&run_cost);
> >
> > I couldn't find a query that would reach this code path with
> > fpextra == NULL, but I agree the current code is fragile.
> > So I think it's a good idea to add the check before accessing
> > the field.
>
> We get here only when called from add_foreign_ordered_paths() or
> add_foreign_final_paths(), in which cases fpextra is always set, so it
> cannot be NULL. No?
>
> False.
>
> In the function *postgresGetForeignRelSize* there is one call,
> where fpextra is NULL.
I think Etsuro-san meant that the problematic code path is only reachable
when estimate_path_cost_size() is called from add_foreign_ordered_paths() or
add_foreign_final_paths(), and in those cases, fpextra is guaranteed to
be non-NULL. In other cases, such as postgresGetForeignRelSize(),
fpextra can be NULL, but the code path in question isn't reached - for example,
because pathkeys is NIL.
As I mentioned earlier, I haven't found a case where this actually causes
a crash, so Etsuro-san's analysis seems valid. That said, I still think
it's safer to guard against NULL by checking fpextra before accessing
its fields, as is done elsewhere.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
