Re: Defects with invalid stats data for expressions in extended stats

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>
Subject: Re: Defects with invalid stats data for expressions in extended stats
Date: 2026-02-27 06:51:40
Message-ID: 92BA3F52-47FB-49F2-A156-551D7BFC326E@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Feb 27, 2026, at 12:25, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Feb 26, 2026 at 10:52:48PM -0500, Corey Huinker wrote:
>> Patch applies for me, but there seems to be some user-specific stuff in the
>> test, which causes it to fail:
>
> Yep. I've noticed that in the CI a few minutes ago. I have switched
> the tests to use a query where the owner does not show up, leading to
> the same coverage without the user-dependency blip. I have checked
> that this version cools down the CI.
>
>> A nitpick about the test - it uses a plpgsql function when we've been
>> moving such trivial functions to SQL standard function bodies for a while
>> now, and they were introduced back in v14 so there's no backporting
>> concern.
>
> No, that's on purpose. Using a SQL function with a body would not
> trigger the problem with the stats loaded at the end of the SQL test
> as we would skip the fatal call of statext_expressions_load(). Based
> on your confusion, I guess that a note to document that is in order,
> at least, so as nobody comes with the idea of changing the definition
> of this function..
> --
> Michael
> <v2-0001-Fix-two-defects-with-extended-statistics-for-expr.patch><v2-0002-test_custom_types-Test-module-for-custom-data-typ.patch>

A few small comments from an eyeball review:

1 - 0001
```
stats[i] = examine_attribute(expr);

+ /*
+ * If the expression has been found as non-analyzable, give up. We
+ * will not be able to build extended stats with it.
+ */
+ if (stats[i] == NULL)
+ {
+ pfree(stats);
+ return NULL;
+ }
```

Here stats itself is destroyed, but memory pointed by stats[0]~stats[i-1] are not free-ed, those memory are returned from examine_attribute() by palloc0_object().

2 - 0002
```
/*
* int_custom_typanalyze_invalid
*
* This function returns sets some invalid stats data, letting the caller know
* that we are safe for an analyze, returning true.
```

“This function returns sets …”, is “returns” a typo and not needed?

3 - 0002
```
+-- Dummy function used for expression evaluations.
+-- Note that this function does not use a function body on purpose, so as
+-- external statistics can be loaded from it.
+CREATE OR REPLACE FUNCTION func_int_custom (p_value int_custom)
+ RETURNS int_custom LANGUAGE plpgsql AS $$
+ BEGIN
+ RETURN p_value;
+ END; $$;
```

The comment says “this function does not use a function body”, but the function has a body. This appears in two places.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-02-27 07:25:41 Funny behavior in event trigger code with CREATE OR REPLACE VIEW and column additions
Previous Message Bertrand Drouvot 2026-02-27 06:45:29 Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version()