On Wed, Oct 28, 2026 at 9:55 AM John Naylor <[email protected]> wrote: > > every major release would need a matching pg_upgrade patch to teach it > > about all the transformations that are required, and when they should > > error out, > > Most of the time, it's just going to be new columns containing '0' or > 'null', isn't it? But maybe I'm missing something, but it seems to me > that most catalogs' form or semantics don't change all that much. As I > mentioned to Tom, the only upgrade that the prototype tried with the > (almost) full regression database was 18 -> 20devel.
Yeah, I think most of the time it is, but I suspect it will take only a few nasty counterexamples to ruin your day. If you can make this work with every catalog change we've had in the last, idk, 7 years, then maybe it's worth considering, but I have a feeling that there are going to be some where it's pretty unpleasant. I'm willing to be proven wrong. > For complex cases like that, you'd have to have a separate step when > the system is fully running, and that's after the main row-by-row > catalog migration has completed (i.e. the merge with the new binary's > bootstrap data) and after the node trees have been updated. So you can > allocate OIDs and call ChooseConstraintName() etc. So, it'd be a pain > in the rear at times, but I don't think it's going to be the same > level of sadness that some of our users encounter with pg_upgrade. I think this only works if you can guarantee that this extra step succeeds. Otherwise you'd have to roll back after starting the new system. -- Robert Haas Databricks
