Date: Thu, 24 Apr 2025 08:37:56 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Greg Sabino Mullane <htamfids@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_upgrade-breaking release
Message-ID: <aAowpA0MW34MDAKR@momjian.us>
References: <aAoqiOt-R_eCiaSA@momjian.us>
 <CAKAnmmKTVP2E_0-SySVg-4rmjAY7T2Xs_eUgRRqqJTpWzuYE9g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKAnmmKTVP2E_0-SySVg-4rmjAY7T2Xs_eUgRRqqJTpWzuYE9g@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aAowpA0MW34MDAKR%40momjian.us>
Precedence: bulk

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, which was already a requirement for those going the other direction in
> the past (checksums -> no checksums). And I also assume that "most people" are
> already running with checksums enabled.
> 
> 
>       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.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.