BUG #18375: requested statistics kind "f" is not yet built for statistics object 16722

The following bug has been logged on the website:

Bug reference:      18375
Logged by:          Horst Reiterer
Email address:      horst.reiterer@fabasoft.com
PostgreSQL version: 15.6
Operating system:   AlmaLinux release 9.3 x86_64
Description:        

Since upgrading from 15.5 to 15.6, the following error occurs once during a
test run:

  requested statistics kind "f" is not yet built for statistics object
16722
  mcv.c:577 statext_mcv_load
  Statement: DELETE FROM test WHERE (col3 IN
(501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,51]

Definitions:

CREATE TABLE test (
  col1 bigint NOT NULL,
  col2 bigint NOT NULL,
  col3 integer NOT NULL,
  col4 integer NOT NULL,
  col5 character varying(254) NOT NULL
);
CREATE UNIQUE INDEX index1 ON test USING btree (col1, col2, col3, col4);
CREATE INDEX index2 ON test USING btree (col2, upper((col5)::text)
varchar_pattern_ops, col3, col1);
CREATE STATISTICS stat1 (mcv) ON col2, col3 FROM test;
CREATE STATISTICS stat2 (mcv) ON col2, col3, upper(col5::text) FROM test;
CREATE STATISTICS stat3 (mcv) ON col1, col2, col3 FROM test;
CREATE STATISTICS stat4 (mcv) ON col1, col2, col3, upper(col5::text) FROM
test;

Before 15.6, we haven't see this error. Unfortunately, I cannot reproduce
the issue with a minimal test case. Interestingly, the error states that
statistics for kind "f" are not yet built. If I'm not mistaken, "f"
corresponds to STATS_EXT_DEPENDENCIES, which we're not using anywhere in the
installation.

This particular PostgreSQL installation is used in an automated test
environment with default settings except for cursor_tuple_fraction = 1.0,
max_prepared_transactions = 100, and higher memory settings / resource
limits. The database itself was not upgraded from 15.5 to 15.6, it was
created with 15.6. The table/indexes/statistics were created before starting
tests and the time between table creation and the error occurrence was
around 19 minutes. We don't trigger analyze explicitely during this run.

My understanding is that this particular error represents an internal
inconsistency and cannot be caused by our particular statistics definitions.
Is this a known issue?

Cheers,

Horst Reiterer