Re: Dump statistic issue with index on expressions

Hi, Maksim!

On Wed, Feb 25, 2026 at 6:37 PM Maksim.Melnikov
<m.melnikov@postgrespro.ru> wrote:
> There is an issue on new feature dump statistics related to index
> processing.
> In case when table has more then one index and if one of them is index
> on expressions
> we can get error like this:
>
> pg_dump --verbose --statistics-only > /dev/null
> ...
> pg_dump: reading subscriptions
> pg_dump: reading subscription membership of tables
> pg_dump: reading dependency data
> pg_dump: saving encoding = UTF8
> pg_dump: saving "standard_conforming_strings = on"
> pg_dump: saving "search_path = "
> pg_dump: error: could not find index attname "source_system"
>
> For clarity, schema ddl attached
>
> CREATE TABLE test_table_stats (
>      id uuid NOT NULL,
>      body jsonb,
>      source_system character varying,
>      source_id character varying,
>      model_name character varying NOT NULL
> );
>
> CREATE INDEX test_table_stats_source_system_text ON test_table_stats
> USING btree (upper((source_system)::text));
> CREATE UNIQUE INDEX test_table_stats_json_system_un ON test_table_stats
> USING btree (source_system, source_id, model_name);
>
> When pg_dump sequentially process indexes in case when index is
> processed after index on expression,
> it can use index attrs names of previously processed index. I've
> attached simple patch to fix it.

I see this is a bug indeed: an index with no expression can get its
indAttNames and nindAttNames from the previous index.  But I didn't
manage to reproduce your case.  dumpRelationStats_dumper() only
iterates indexes with pg_stats entry, and those are indexes with
expressions.  Could you give more details on how did you reproduce
user-facing error?  Which particular git commit did you use?  How did
you fill the database step by step?

------
Regards,
Alexander Korotkov
Supabase