Re: PoC: true in-place major version upgrades

John Naylor <johncnaylorls(at)gmail(dot)com> writes:
> *** Catalogs (TODO)

> While the PoC sidesteps this entirely for now, this is actually how I
> started. About a year and half ago, I experimented with catalog header
> annotations so that the usual couple hundred lines of Perl would
> generate the code that transforms the catalog tuples. Earlier this
> year, I turned that into a throwaway "offline upgrade" (i.e. no WAL)
> prototype. That exercise indicated that this method could feasibly
> handle all catalog schema changes since PG12. Example from pg_class:

I'm just really, really skeptical that this is practical for
anything except the most trivial changes (such as your two examples).
You already mentioned that stored expressions (node trees) won't work,
but what about cases where we move information across catalogs, or
create things that just weren't there before? A handy example is the
recent changes to make pg_constraint entries for column NOT NULL
constraints. Adding pg_depend entries for linkages where we didn't
formerly require one seems like another plausible-and-hard-to-implement
case. So I'm afraid where this is going to lead us is either a
straitjacket on what we can change in the catalog representation,
or an additional requirement for even more complex, hard-to-test code
that has to be written in order to put forward such changes. We
built pg_upgrade the way we did precisely to avoid such problems,
and I don't want to give that up.

> 2) At some point, catalog OIDs (e.g. between 10k and 12k) that now
> vary between versions should be made immutable. Technically, it's not
> necessary, but it makes it a lot nicer.

The core reason why that's not so today is that the set of
pg_collation entries made by initdb depends on the platform. I don't
think you're going to be able to make that not be the case, at least
not without significant downsides.

regards, tom lane