| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: statatt_build_stavalues->LOCAL_FCINFO wrong number |
| Date: | 2026-06-29 08:23:41 |
| Message-ID: | akIrjdIIRViUT2o3@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jun 27, 2026 at 01:25:39PM +0800, jian he wrote:
> That mistake is harmless now, but if somebody use
> LOCAL_FCINFO(fcinfo, 1), then it may have potential problems.
> So let's try to use InputFunctionCallSafe instead, see attached.
It's an overallocation, harmless still incorrect. This also exists on
REL_18_STABLE; this code has been moved on HEAD to its current
location from atttribute_stats.c.
> I found this while trying to use InputFunctionCallSafe inside array_in_safe.
> Should we consider fully refactoring array_in_safe to use it too?
Yep, let's do this cleanup in array_in_safe() as well. I was
wondering about doing that only once v20 opens up, but array_in_safe()
is new in v19. So let's just make the code right now rather than
create an inconsistency before v19 gets released.
Thanks for the report. Will do something for both spots.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tender Wang | 2026-06-29 08:32:16 | Re: Fix HAVING-to-WHERE pushdown with mismatched operator families |
| Previous Message | Kyotaro Horiguchi | 2026-06-29 08:22:07 | Re: Report oldest xmin source when autovacuum cannot remove tuples |