On Wed, 21 Jan 2026 at 16:45, David Geier <[email protected]> wrote: > > How do we usually go about such backwards-compatibility breaking > changes?
When it concerns a bug, we mention the change in the release notes with a warning to reindex affected indexes to be sure no known corruption remains. See e.g. the final entry in the PG18 release notes' migration section here: https://www.postgresql.org/docs/18/release-18.html#RELEASE-18-MIGRATION. > Could we have pg_upgrade reindex all GIN indexes? Would that be > acceptable? No. We'd handle this like any other collation/opclass fixes; we ask users to reindex their indexes in their own time after they've upgraded their cluster. Note that in this case it concerns an issue with just one GIN opclass, not all GIN indexes; so even if we were to address this in pg_upgrade it wouldn't be a correct choice to reindex every GIN index, as only a subset of those would be affected by this issue. Generally speaking, pg_upgrade doesn't concern itself with the validity of the data structures that are described by the catalogs that it upgrades, it only concerns itself with that it correctly transcribes the catalogs from one version to another, and that the data files of the old cluster are transfered correctly without changes. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
