Re: pg_upgrade-breaking release

On Thu, Apr 24, 2025 at 08:37:56AM -0400, Bruce Momjian wrote:
> On Thu, Apr 24, 2025 at 08:35:10AM -0400, Greg Sabino Mullane wrote:
> > On Thu, Apr 24, 2025 at 8:12 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > Do we think most people are _not_ going to use pg_upgrade now that we
> > are defaulting to checksums being enabled by default in PG 18?
> >
> >
> > I cannot imagine this would stop anyone from upgrading. It's one additional
> > flag

Yeah. We've had this before, with integer datetimes and others. People will
notice the friction, but v18 won't be a shock in this respect.

> >   And if so, do we think we are ever going to have a
> > storage-format-changing release where pg_upgrade cannot be used?
> >
> >
> > Seems very unlikely, that would kind of go against the whole purpose of
> > pg_upgrade.
>
> When I wrote pg_upgrade, I assumed at some point the value of changing
> the storage format would outweigh the value of allowing in-place
> upgrades. I guess that hasn't happened yet.

Having pg_upgrade has made PostgreSQL popular for applications with high
availability and high data volumes, applications that would have ruled out
PostgreSQL before pg_upgrade. In other words, adding pg_upgrade changed the
expectations of PostgreSQL. A storage format break is less plausible now than
it was in the early years of having pg_upgrade.

I think a prerequisite for a storage format break would be a foolproof upgrade
recipe based on logical replication techniques. The step having downtime
would need to be no slower than pg_upgrade. Even with that, the double
storage requirement isn't negligible. Hence, it wouldn't be a given that we'd
regard the storage format break as sufficiently-valuable.