| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org> |
| Subject: | Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c) |
| Date: | 2021-04-12 17:04:24 |
| Message-ID: | 2936273.1618247064@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:
> Em seg., 12 de abr. de 2021 às 03:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
(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.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2021-04-12 17:05:53 | Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c) |
| Previous Message | Tomas Vondra | 2021-04-12 17:03:11 | Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c) |