MIME-Version: 1.0
References: <be5fc489-587e-421f-bbb8-adb43cfd50f4@postgrespro.ru>
 <CAPpHfduU3ysyGUUdW53uV4PhXOxBcpyLk_ACbMrgownLo4DE6w@mail.gmail.com>
 <987e51f7-e266-4377-8f44-5a1653c161bc@postgrespro.ru>
In-Reply-To: <987e51f7-e266-4377-8f44-5a1653c161bc@postgrespro.ru>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Sat, 30 May 2026 22:36:39 +0300
Message-ID: 
 <CAPpHfdvkU3YHvzPxaT=QVXMef5j3+-GirOc_m=aTohV7ZMpsPw@mail.gmail.com>
Subject: Re: Dump statistic issue with index on expressions
To: "Maksim.Melnikov" <m.melnikov@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfdvkU3YHvzPxaT%3DQVXMef5j3%2B-GirOc_m%3DaTohV7ZMpsPw%40mail.gmail.com>
Precedence: bulk

Hi, Maksim!

On Wed, May 20, 2026 at 12:52=E2=80=AFPM Maksim.Melnikov
<m.melnikov@postgrespro.ru> wrote:
> On 5/11/26 02:42, Alexander Korotkov wrote:
> > On Wed, Feb 25, 2026 at 6:37=E2=80=AFPM 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 =3D UTF8
> >> pg_dump: saving "standard_conforming_strings =3D on"
> >> pg_dump: saving "search_path =3D "
> >> 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_stat=
s
> >> 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
> >
> >
> Sorry for delay, I've tried to reproduce this issue for some time and
> detect that it isn't reproducable on vanilla postgresql.
> It seems, that our fork generate more records for pg_statistics unlike
> vanilla, that generate records only for indexes with expressions,
> more details can be found here in src/backend/commands/analyze.c
>
> static void
> do_analyze_rel(Relation onerel, VacuumParams *params,
>                 List *va_cols, AcquireSampleRowsFunc acquirefunc,
>                 BlockNumber relpages, bool inh, bool in_outer_xact,
>                 int elevel)
> {
> ......
>              thisdata->tupleFract =3D 1.0; /* fix later if partial */
>              if (indexInfo->ii_Expressions !=3D NIL && va_cols =3D=3D NIL=
)
>              {
>                  ListCell   *indexpr_item =3D
> list_head(indexInfo->ii_Expressions);
>
>                  thisdata->vacattrstats =3D (VacAttrStats **)
>                      palloc(indexInfo->ii_NumIndexAttrs *
> sizeof(VacAttrStats *));
> .....
>                  thisdata->attr_cnt =3D tcnt;
>
>
> Anyway, it seems code, reported before, isn't ideal and prone to bugs.
> In my opinion better fix it.
> Hope it will be helpful.

Thank you.  Now this is clear.  No user-facing error, but an internal
inconsistency.  I'm going to push (and backpatch) this after release
freeze is lifted.

------
Regards,
Alexander Korotkov
Supabase