Re: Avoid possible dereference null pointer (contrib/postgres_fdw/postgres_fdw.c)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid possible dereference null pointer (contrib/postgres_fdw/postgres_fdw.c)
Date: 2025-06-17 11:37:06
Message-ID: CAEudQApWN9Lf0KnVYx=LDqDWvnFh-eChZTWRpKOkCiMETwrMtA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em ter., 17 de jun. de 2025 às 06:09, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
escreveu:

> Hi,
>
> On Tue, Jun 17, 2025 at 2:38 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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.

/*
* Get cost/size estimates with help of remote server. Save the
* values in fpinfo so we don't need to do it again to generate the
* basic foreign path.
*/
estimate_path_cost_size(root, baserel, NIL, NIL, NULL,
&fpinfo->rows, &fpinfo->width,
&fpinfo->disabled_nodes,
&fpinfo->startup_cost, &fpinfo->total_cost);

best regards,
Ranier Vilela

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-06-17 11:42:55 Re: wrong comments in rewriteTargetListIU
Previous Message Andres Freund 2025-06-17 11:22:25 Re: Transactional behavior of pg_create_logical_replication_slot