Date: Thu, 24 Apr 2025 07:08:50 -0700
From: Noah Misch <noah@leadboat.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Greg Sabino Mullane <htamfids@gmail.com>,
	PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_upgrade-breaking release
Message-ID: <20250424140850.04.nmisch@google.com>
References: <aAoqiOt-R_eCiaSA@momjian.us>
 <CAKAnmmKTVP2E_0-SySVg-4rmjAY7T2Xs_eUgRRqqJTpWzuYE9g@mail.gmail.com>
 <aAowpA0MW34MDAKR@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <aAowpA0MW34MDAKR@momjian.us>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: <https://www.postgresql.org/message-id/20250424140850.04.nmisch%40google.com>
Precedence: bulk

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