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 <br...@momjian.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.
