Jeff Davis <pgsql@j-davis.com> writes:
> It's also strange that copperhead is consistently failing on 12 with:
> pg_restore: while PROCESSING TOC:
> pg_restore: from TOC entry 4163; 0 0 STATISTICS DATA "vcharidx" (no
> owner)
> pg_restore: error: could not execute query: ERROR: column "text" of
> relation "vcharidx" does not exist
Ugh. I see what is happening, and it's going to be problematic to
fix: our heuristics for assigning names to index expression columns
are not very consistent/stable. It didn't matter up to now, but
this patch assumes that it can reference index columns by name.
The index in question is made in btree_gist's tests:
CREATE INDEX vcharidx ON vchartmp USING GIST ( text(a) );
The index column will be given the name "text". However, it
dumps as
CREATE INDEX vcharidx ON public.vchartmp USING gist (((a)::text));
and when *that* gets loaded, the index column is given the name
"a", because FigureColname treats function-like constructs
differently from cast-like constructs. Then
pg_restore_attribute_stats unsurprisingly fails. I think the
reason that Andrew and I aren't seeing that is that we are
using machines that are fast enough to shut down the DB before
autovacuum gets around to populating some stats for this
expression index.
We have dealt with some similar issues in the past, and the
solution was to allow index columns to be referenced by
column number not name. (ALTER INDEX ... ALTER COLUMN ...
SET STATISTICS does that, not sure if there are other places.)
Recommend adopting the same solution here.
regards, tom lane
