Andres Freund <andres@anarazel.de> writes:
> ISTM that if we go down this path, we should split (not now, but either
> still in v12, or *early* in v13), the sets of indexes that are intended
> to a) not being used for catalog queries b) may be skipped for index
> insertions. It seems pretty likely that somebody will otherwise soon
> introduce an heap_update() somewhere into the index build process, and
> it'll work just fine in testing due to HOT.
Given the assertions you added in CatalogIndexInsert, I'm not sure
why that's a big hazard?
> I kinda wonder if there's not a third approach hiding somewhere here. We
> could just stop updating pg_class in RelationSetNewRelfilenode() in
> pg_class, when it's an index on pg_class.
Hmm ... are all those indexes mapped? I guess so. But don't we need
to worry about resetting relfrozenxid?
regards, tom lane