Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)
От | Tomas Vondra |
---|---|
Тема | Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c) |
Дата | |
Msg-id | 44db464c-b9e2-9d37-5c29-6f784a3fe7bd@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: