From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17880: Uninitialised value used when analyzing a table with
 an inheritance tree containing no children
In-reply-to: <17880-9282037c923d856e@postgresql.org>
References: <17880-9282037c923d856e@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 31 Mar 2023 10:00:02 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <435879.1680270035.1@sss.pgh.pa.us>
Date: Fri, 31 Mar 2023 09:40:35 -0400
Message-ID: <435880.1680270035@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/435880.1680270035%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> As I can see, this error is explained by the fact that
> acquire_inherited_sample_rows() can exit before setting
>     *totalrows = 0;
>     *totaldeadrows = 0;
> so variables declared in do_analyze_rel() as
> 	double		totalrows,
> 				totaldeadrows;
> stay uninitialised and totalrows passed to vac_update_relstats() where it
> triggers the valgrind complaint.

Good catch!

> On a quick glance, the peer functions acquire_sample_rows(),
> postgresAcquireSampleRowsFunc(), file_acquire_sample_rows() can't exit
> without setting totalrows/totaldeadrows, so maybe
> acquire_inherited_sample_rows() deserves fixing (or maybe those variables
> can be initialized in do_analyze_rel()).

Yeah, I'd put the blame on acquire_inherited_sample_rows.  Its head
comment says it has the same API as acquire_sample_rows, and that
one's comment says that totalrows/totaldeadrows are always set.
Will fix, thanks.

			regards, tom lane