Re: statatt_build_stavalues->LOCAL_FCINFO wrong number

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

In response to

Responses

Browse pgsql-hackers by date

  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