Re: Proposal: In-Place upgrade concept

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> My thinking is that when a page in the old format is read in, it's
> converted to the new format before doing anything else with it.

Yeah, I'm with Heikki on this. What I see as a sane project definition
is:

* pg_migrator or equivalent to convert the system catalogs
* a hook in ReadBuffer to allow a data page conversion procedure to
be applied, on the basis of checking for old page layout version.

I think insisting on a downgrade option is an absolutely certain way
of guaranteeing that the project will fail.

I'm not sure it's feasible to expect that we can change representations
of user-defined types, either. I don't see how you would do that
without catalog access (to look up the UDT), and the page conversion
procedure is going to have to be able to operate without catalog
accesses. (Thought experiment: a page is read in during crash recovery
or PITR slave operation, and discovered to have the old format.)

BTW, I thought of a likely upgrade problem that we haven't discussed
(AFAIR) in any of the many threads on this subject. What about an index
access method change that involves an index-wide restructuring, such
that it can't be done one page at a time? A plausible example is
changing hash indexes to have multiple buckets per page. Presumably
you can fix the index with REINDEX, but that doesn't meet the goal of
limited downtime, if the index is big. Is there another way?

regards, tom lane