Horton

Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)

Tomas Vondra <tomas.vondra@enterprisedb.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Ranier Vilela <ranier.vf@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Justin Pryzby <pryzby@telsasoft.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Tomas Vondra <tomas.vondra@postgresql.org>
Date: 2021-04-13T22:55:55Z
Lists: pgsql-hackers 

On 4/12/21 7:04 PM, Tom Lane wrote:
> Ranier Vilela <ranier.vf@gmail.com> writes:
>> Em seg., 12 de abr. de 2021 às 03:04, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
>>> It would be wrong, though, or at least not have the same effect.
> 
>> I think that you speak about fill pointers with 0 is not the same as fill
>> pointers with NULL.
> 
> No, I mean that InvalidBlockNumber isn't 0.
> 
>> I was confused here, does the patch follow the pattern and fix the problem
>> or not?
> 
> Your patch seems fine.  Justin's proposed improvement isn't.
> 

Pushed.

> (I'm not real sure whether there's any *actual* bug here --- would we
> really be looking at either ctid or tableoid of this temporary tuple?
> But it's probably best to ensure that they're valid anyway.)>

Yeah, the tuple is only built so that we can pass it to the various
selectivity estimators. I don't think anything will be actually looking
at those fields, but initializing them seems easy enough.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Initialize t_self and t_tableOid in statext_expressions_load