Re: Possible pointer var TupleDesc rettupdesc used not initialized (src/backend/optimizer/util/clauses.c)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Possible pointer var TupleDesc rettupdesc used not initialized (src/backend/optimizer/util/clauses.c)
Date: 2021-05-25 16:09:18
Message-ID: 1220935.1621958958@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> writes:
> Possible pointer TupleDesc rettupdesc used not initialized?
> if (!isNull) at line 4346 taking a true branch, the function
> check_sql_fn_retval at line 4448 can use rettupdesc uninitialized.

This seems to have been introduced by the SQL-function-body patch.

After some study, I concluded that the reason we haven't noticed
is that the case is nearly unreachable: check_sql_fn_retval never
consults the rettupdesc unless the function result type is composite
and the tlist length is more than one --- and we eliminated the latter
case earlier in inline_function.

There is an exception, namely if the single tlist item fails to
be coercible to the output type, but that's hard to get to given
that it'd have been checked while defining the SQL-body function.
I did manage to reproduce a problem after turning off
check_function_bodies so I could create a broken function.

In any case, inline_function has no business assuming that
check_sql_fn_retval doesn't need a valid value.

The simplest way to fix this seems to be to move the code that
creates "fexpr" and calls get_expr_result_type, so that we always
do that even for SQL-body cases. We could alternatively use some
other way to obtain a result tupdesc in the SQL-body path; but
creating the dummy FuncExpr node is cheap enough that I don't
think it's worth contortions to avoid doing it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-05-25 16:14:58 Re: array_cat anycompatible change is breaking xversion upgrade tests
Previous Message Egor Rogov 2021-05-25 16:00:46 Re: automatic analyze: readahead - add "IO read time" log message