Hi Matthias, On 21.01.2026 21:50, Matthias van de Meent wrote: > 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.
Thanks for the clarifications and the link to the release notes. That's very helpful. Then I know how to move on and will update the patch accordingly. -- David Geier
