From: "Birler, Altan" <altan.birler@tum.de>
To: "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Subject: Segmentation fault in var_is_nonnullable when running query with
 COUNT() on 42473b3b
Thread-Topic: Segmentation fault in var_is_nonnullable when running query with
 COUNT() on 42473b3b
Thread-Index: AQHcYQ6ueC49PqulvUOOYoC7MxgWGQ==
Date: Sat, 29 Nov 2025 09:12:34 +0000
Message-ID: <132d4da23b844d5ab9e352d34096eab5@tum.de>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/132d4da23b844d5ab9e352d34096eab5%40tum.de>
Precedence: bulk

To whom it may concern,

When running queries on the latest master 87c6f8b047d5b0790e6f8b8532f4adf58=
dc60f67 , I have found that the following query leads to a segmentation fau=
lt on the backend:
```
SELECT CAST(NULL AS float8) AS result FROM (SELECT DISTINCT NULL AS key UNI=
ON ALL SELECT NULL AS key) T1 WHERE T1.key IN ('a', 'b') AND T1.key IS NOT =
NULL GROUP BY T1.key HAVING COUNT(T1.key) =3D ANY (ARRAY[2]) AND T1.key =3D=
 'foo';
```

I have run git bisect and got the following output:
```
42473b3b31238b15cc3c030b4416b2ee79508d8c is the first bad commit
commit 42473b3b31238b15cc3c030b4416b2ee79508d8c
Author: David Rowley <drowley@postgresql.org>
Date:   Thu Nov 27 10:43:28 2025 +1300

    Have the planner replace COUNT(ANY) with COUNT(*), when possible

    This adds SupportRequestSimplifyAggref to allow pg_proc.prosupport
    functions to receive an Aggref and allow them to determine if there is =
a
    way that the Aggref call can be optimized.

    Also added is a support function to allow transformation of COUNT(ANY)
    into COUNT(*).  This is possible to do when the given "ANY" cannot be
    NULL and also that there are no ORDER BY / DISTINCT clauses within the
    Aggref.  This is a useful transformation to do as it is common that
    people write COUNT(1), which until now has added unneeded overhead.
    When counting a NOT NULL column.  The overheads can be worse as that
    might mean deforming more of the tuple, which for large fact tables may
    be many columns in.

    It may be possible to add prosupport functions for other aggregates.  W=
e
    could consider if ORDER BY could be dropped for some calls, e.g. the
    ORDER BY is quite useless in MAX(c ORDER BY c).

    There is a little bit of passing fallout from adjusting
    expr_is_nonnullable() to handle Const which results in a plan change in
    the aggregates.out regression test.  Previously, nothing was able to
    determine that "One-Time Filter: (100 IS NOT NULL)" was always true,
    therefore useless to include in the plan.

    Author: David Rowley <dgrowleyml@gmail.com>
    Reviewed-by: Corey Huinker <corey.huinker@gmail.com>
    Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>
    Discussion: https://postgr.es/m/CAApHDvqGcPTagXpKfH=3DCrmHBqALpziThJEDs=
_MrPqjKVeDF9wA@mail.gmail.com

 contrib/postgres_fdw/expected/postgres_fdw.out |  20 ++--
 src/backend/optimizer/plan/initsplan.c         |  20 +---
 src/backend/optimizer/util/clauses.c           |  73 +++++++++++++++
 src/backend/utils/adt/int8.c                   |  49 +++++++++-
 src/include/nodes/supportnodes.h               |  25 +++++
 src/include/optimizer/optimizer.h              |   3 +
 src/test/regress/expected/aggregates.out       | 125 +++++++++++++++++++++=
++--
 src/test/regress/sql/aggregates.sql            |  44 ++++++++-
 src/tools/pgindent/typedefs.list               |   1 +
 9 files changed, 324 insertions(+), 36 deletions(-)
bisect found first bad commit
```

Here are the steps I can take to reproduce the issue on a clean clone of th=
e git repository:
```
git checkout 42473b3b31238b15cc3c030b4416b2ee79508d8c
meson setup -Dprefix=3D$(pwd)/target-release build-release
ninja -C build-release/ install
rm -rf db
target-release/bin/initdb -D db
echo "SELECT CAST(NULL AS float8) AS result FROM (SELECT DISTINCT NULL AS k=
ey UNION ALL SELECT NULL AS key) T1 WHERE T1.key IN ('a', 'b') AND T1.key I=
S NOT NULL GROUP BY T1.key HAVING COUNT(T1.key) =3D ANY (ARRAY[2]) AND T1.k=
ey =3D 'foo';" | target-release/bin/postgres --single -D db postgres
```

Here is the output that I get:
```

PostgreSQL stand-alone backend 19devel
backend> Segmentation fault (core dumped)
```

I have tried to minimize the query and I still get an error with the follow=
ing smaller query:
```
SELECT 1 FROM (VALUES (NULL),(NULL)) AS t(key) GROUP BY key HAVING COUNT(ke=
y) =3D ANY (ARRAY[2]);
```

I have also done a debug run with:
```
meson setup -Dprefix=3D$(pwd)/target-debug --buildtype=3Ddebug -Dcassert=3D=
true build-debug
ninja -C build-debug/ install
rm -rf db
target-debug/bin/initdb -D db
echo "SELECT 1 FROM (VALUES (NULL),(NULL)) AS t(key) GROUP BY key HAVING CO=
UNT(key) =3D ANY (ARRAY[2]);" | target-debug/bin/postgres --single -D db po=
stgres
```

I still get the same output:
```

PostgreSQL stand-alone backend 19devel
backend> Segmentation fault (core dumped)
```

GDB gives me the following backtrace for the debug run:
```
#0  0x0000555555a2db88 in var_is_nonnullable (root=3D0x0, var=3D0x5555565ca=
058, use_rel_info=3Dfalse) at ../src/backend/optimizer/util/clauses.c:4293
#1  0x0000555555a2dc7f in expr_is_nonnullable (root=3D0x0, expr=3D0x5555565=
ca058, use_rel_info=3Dfalse) at ../src/backend/optimizer/util/clauses.c:433=
0
#2  0x0000555555c8432c in int8inc_support (fcinfo=3D0x7fffffffc4c0) at ../s=
rc/backend/utils/adt/int8.c:837
#3  0x0000555555dd1950 in FunctionCall1Coll (flinfo=3D0x7fffffffc520, colla=
tion=3D0, arg1=3D140737488340368) at ../src/backend/utils/fmgr/fmgr.c:1140
#4  0x0000555555dd28c9 in OidFunctionCall1Coll (functionId=3D6236, collatio=
n=3D0, arg1=3D140737488340368) at ../src/backend/utils/fmgr/fmgr.c:1418
#5  0x0000555555a2da62 in simplify_aggref (aggref=3D0x5555565c9b38, context=
=3D0x7fffffffc910) at ../src/backend/optimizer/util/clauses.c:4236
#6  0x0000555555a2ac47 in eval_const_expressions_mutator (node=3D0x5555565c=
9b38, context=3D0x7fffffffc910) at ../src/backend/optimizer/util/clauses.c:=
2641
#7  0x0000555555a2a47c in estimate_expression_value (root=3D0x5555565c6cc8,=
 node=3D0x5555565ae4d8) at ../src/backend/optimizer/util/clauses.c:2421
#8  0x0000555555d3bfa2 in scalararraysel (root=3D0x5555565c6cc8, clause=3D0=
x5555565c8bd0, is_join_clause=3Dfalse, varRelid=3D0, jointype=3DJOIN_INNER,=
 sjinfo=3D0x0) at ../src/backend/utils/adt/selfuncs.c:1924
#9  0x00005555559b2157 in clause_selectivity_ext (root=3D0x5555565c6cc8, cl=
ause=3D0x5555565c8bd0, varRelid=3D0, jointype=3DJOIN_INNER, sjinfo=3D0x0, u=
se_extended_stats=3Dtrue) at ../src/backend/optimizer/path/clausesel.c:885
#10 0x00005555559b1039 in clauselist_selectivity_ext (root=3D0x5555565c6cc8=
, clauses=3D0x5555565c8e50, varRelid=3D0, jointype=3DJOIN_INNER, sjinfo=3D0=
x0, use_extended_stats=3Dtrue) at ../src/backend/optimizer/path/clausesel.c=
:136
#11 0x00005555559b0f74 in clauselist_selectivity (root=3D0x5555565c6cc8, cl=
auses=3D0x5555565c8e50, varRelid=3D0, jointype=3DJOIN_INNER, sjinfo=3D0x0) =
at ../src/backend/optimizer/path/clausesel.c:106
#12 0x00005555559b7eb6 in cost_agg (path=3D0x5555565c9c58, root=3D0x5555565=
c6cc8, aggstrategy=3DAGG_SORTED, aggcosts=3D0x7fffffffd010, numGroupCols=3D=
1, numGroups=3D2, quals=3D0x5555565c8e50, disabled_nodes=3D0, input_startup=
_cost=3D0.035000000000000003,
    input_total_cost=3D0.040000000000000001, input_tuples=3D2, input_width=
=3D32) at ../src/backend/optimizer/path/costsize.c:2863
#13 0x0000555555a39ff6 in create_agg_path (root=3D0x5555565c6cc8, rel=3D0x5=
555565a1ba8, subpath=3D0x5555565c9bc8, target=3D0x5555565c98d8, aggstrategy=
=3DAGG_SORTED, aggsplit=3DAGGSPLIT_SIMPLE, groupClause=3D0x5555565c8ea0, qu=
al=3D0x5555565c8e50, aggcosts=3D0x7fffffffd010, numGroups=3D2)
    at ../src/backend/optimizer/util/pathnode.c:3044
#14 0x0000555555a04cdd in add_paths_to_grouping_rel (root=3D0x5555565c6cc8,=
 input_rel=3D0x5555565c8600, grouped_rel=3D0x5555565a1ba8, partially_groupe=
d_rel=3D0x0, agg_costs=3D0x7fffffffd010, gd=3D0x0, extra=3D0x7fffffffd040) =
at ../src/backend/optimizer/plan/planner.c:7188
#15 0x00005555559fedee in create_ordinary_grouping_paths (root=3D0x5555565c=
6cc8, input_rel=3D0x5555565c8600, grouped_rel=3D0x5555565a1ba8, agg_costs=
=3D0x7fffffffd010, gd=3D0x0, extra=3D0x7fffffffd040, partially_grouped_rel_=
p=3D0x7fffffffcfd8)
    at ../src/backend/optimizer/plan/planner.c:4155
#16 0x00005555559fe8ea in create_grouping_paths (root=3D0x5555565c6cc8, inp=
ut_rel=3D0x5555565c8600, target=3D0x5555565c98d8, target_parallel_safe=3Dtr=
ue, gd=3D0x0) at ../src/backend/optimizer/plan/planner.c:3903
#17 0x00005555559fa6b7 in grouping_planner (root=3D0x5555565c6cc8, tuple_fr=
action=3D0, setops=3D0x0) at ../src/backend/optimizer/plan/planner.c:1828
#18 0x00005555559f9723 in subquery_planner (glob=3D0x5555565a13c0, parse=3D=
0x5555565a14d0, plan_name=3D0x0, parent_root=3D0x0, hasRecursion=3Dfalse, t=
uple_fraction=3D0, setops=3D0x0) at ../src/backend/optimizer/plan/planner.c=
:1251
#19 0x00005555559f7828 in standard_planner (parse=3D0x5555565a14d0, query_s=
tring=3D0x55555659ff10 "SELECT 1 FROM (VALUES (NULL),(NULL)) AS t(key) GROU=
P BY key HAVING COUNT(key) =3D ANY (ARRAY[2]);\n", cursorOptions=3D2048, bo=
undParams=3D0x0, es=3D0x0)
    at ../src/backend/optimizer/plan/planner.c:470
#20 0x00005555559f74c9 in planner (parse=3D0x5555565a14d0, query_string=3D0=
x55555659ff10 "SELECT 1 FROM (VALUES (NULL),(NULL)) AS t(key) GROUP BY key =
HAVING COUNT(key) =3D ANY (ARRAY[2]);\n", cursorOptions=3D2048, boundParams=
=3D0x0, es=3D0x0)
    at ../src/backend/optimizer/plan/planner.c:324
#21 0x0000555555bc869d in pg_plan_query (querytree=3D0x5555565a14d0, query_=
string=3D0x55555659ff10 "SELECT 1 FROM (VALUES (NULL),(NULL)) AS t(key) GRO=
UP BY key HAVING COUNT(key) =3D ANY (ARRAY[2]);\n", cursorOptions=3D2048, b=
oundParams=3D0x0, es=3D0x0)
    at ../src/backend/tcop/postgres.c:905
#22 0x0000555555bc886b in pg_plan_queries (querytrees=3D0x5555565c6c78, que=
ry_string=3D0x55555659ff10 "SELECT 1 FROM (VALUES (NULL),(NULL)) AS t(key) =
GROUP BY key HAVING COUNT(key) =3D ANY (ARRAY[2]);\n", cursorOptions=3D2048=
, boundParams=3D0x0)
    at ../src/backend/tcop/postgres.c:1000
#23 0x0000555555bc8ca8 in exec_simple_query (query_string=3D0x55555659ff10 =
"SELECT 1 FROM (VALUES (NULL),(NULL)) AS t(key) GROUP BY key HAVING COUNT(k=
ey) =3D ANY (ARRAY[2]);\n") at ../src/backend/tcop/postgres.c:1198
#24 0x0000555555bcebd3 in PostgresMain (dbname=3D0x555556408a50 "postgres",=
 username=3D0x55555638f8d0 "birler") at ../src/backend/tcop/postgres.c:4775
#25 0x0000555555bcdeb1 in PostgresSingleUserMain (argc=3D5, argv=3D0x555556=
389a80, username=3D0x55555638f8d0 "birler") at ../src/backend/tcop/postgres=
.c:4177
#26 0x000055555598b1e9 in main (argc=3D5, argv=3D0x555556389a80) at ../src/=
backend/main/main.c:227
```

I can reproduce the issue on a non-standalone backend as well with the foll=
owing commands:
```
target-debug/bin/pg_ctl -D db -l logfile -o "-p 55432" start
target-debug/bin/psql -d postgres -p 55432
```

With the following input/output:
```
psql (19devel)
Type "help" for help.

postgres=3D# SELECT 1
FROM (VALUES (NULL),(NULL)) AS t(key)
GROUP BY key
HAVING COUNT(key) =3D ANY (ARRAY[2]);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.
```

I am running on Ubuntu 25.10, GCC version 15.2.0, x86_64 CPU, kernel 6.17.0=
, and GLIBC 2.42.

This issue has no urgency for me; I just wanted to report an issue I have e=
ncountered. Thank you in advance!

Best regards,
Altan Birler
TUM