Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c) - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)
Date
Msg-id 44db464c-b9e2-9d37-5c29-6f784a3fe7bd@enterprisedb.com
Whole thread Raw
In response to Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Converting contrib SQL functions to new style
Next
From: Masahiko Sawada
Date:
Subject: Re: New IndexAM API controlling index vacuum strategies