BUG #19772: ERROR: corrupt MVNDistinct entry for GROUP BY c0, ROLLUP (abs(c0)) with ndistinct statistics

The following bug has been logged on the website:

Bug reference: 19772
Logged by: Alperen Keles
Email address: alpkeles99(at)gmail(dot)com
PostgreSQL version: 18.6
Operating system: Ubuntu 24.04 x86_64 (also macOS arm64)
Description:

Hello,

With an ndistinct extended statistics object on a table, a GROUP BY
that has a plain column in every grouping set and an expression of the
same column in only some of them fails at plan time:

CREATE TABLE t0 (c0 int8, c1 int8);
INSERT INTO t0 VALUES (NULL, NULL);
CREATE STATISTICS t0_s ON c0, c1 FROM t0;
ANALYZE t0;
SELECT c0 FROM t0 GROUP BY c0, ROLLUP (abs(c0));
ERROR: XX000: corrupt MVNDistinct entry
LOCATION: estimate_multivariate_ndistinct, selfuncs.c:4485 (18.6)

CREATE STATISTICS makes ANALYZE store, among other things, the number
of distinct values of each combination of two or more of the listed
columns, and the planner uses those to estimate how many groups a GROUP
BY yields. ROLLUP (abs(c0)) means the grouping sets (c0, abs(c0)) and
(c0), so the planner estimates the group count of each set separately.

The NULL row is not needed: any non-empty table that is analyzed after
the statistics object is created fails the same way (for example 1000
rows of (i % 10, i % 7)), and so does EXPLAIN. The same error comes
from CUBE (abs(c0)), GROUPING SETS ((c0, abs(c0)), (c0)),
GROUP BY abs(c0), ROLLUP (c0), from c0 + 1, c0::text and c0::numeric
instead of abs(c0), from statistics with only the ndistinct kind, on
three columns, or ON c0, abs(c0), and from a view over the query. It
does not happen with a plain GROUP BY c0, abs(c0), with
ROLLUP (c0, abs(c0)), with GROUP BY c0, c1, ROLLUP (abs(c0)), with an
expression over a different column (abs(c1), c0 + c1), with only the
dependencies or mcv kinds, or before the table is analyzed. It is an
ordinary ERROR; the cassert builds do not hit an assertion.

Reproduced on 18.6 (REL_18_STABLE dfbc1507cdb), 19rc1 (REL_19_STABLE
1212d5d33b1) and master a261fc2b722, Ubuntu 24.04 x86_64,
--enable-cassert; also on 18.6 and master on macOS arm64. 14.24
(REL_14_STABLE 14904052e65) runs all of these queries without error.

Found with a query fuzzer.

Regards,
Alperen Keles