Thread: pg_upgrade-breaking release
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? And if so, do we think we are ever going to have a storage-format-changing release where pg_upgrade cannot be used? Maybe it is too late to ask this, but I am asking anyway. -- 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.
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.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
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.
On Thu, Apr 24, 2025 at 8:37 AM Bruce Momjian <bruce@momjian.us> wrote:
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.
It reminds me of TDE, which is an good example of that, in a way. It requires pg_dump or logical replication to go from unencrypted -> encrypted. If core were to have something like that, I guess pg_upgrade could technically support it, but it would be equivalent to pg_dump. We've all been spoiled by that awesome --link option! :)
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
On Thu, Apr 24, 2025 at 08:51:41AM -0400, Greg Sabino Mullane wrote: > On Thu, Apr 24, 2025 at 8:37 AM Bruce Momjian <bruce@momjian.us> wrote: > > 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. > > > It reminds me of TDE, which is an good example of that, in a way. It requires > pg_dump or logical replication to go from unencrypted -> encrypted. If core > were to have something like that, I guess pg_upgrade could technically support > it, but it would be equivalent to pg_dump. We've all been spoiled by that > awesome --link option! :) True on spoiled, but I think TDE is being held back by code complexity, not upgrade complexity. -- 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.
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.
On 2025-Apr-24, Bruce Momjian 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? And if > so, do we think we are ever going to have a storage-format-changing > release where pg_upgrade cannot be used? Peter E posted a patch that allowed pg_upgrade to migrate (rewrite) files from non-checksummed to checksummed, but he appears to have given up on it for this release given an apparent lack of interest. https://postgr.es/m/57957aca-3eae-4106-afb2-3008122b9950@eisentraut.org -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
On Thu, Apr 24, 2025 at 04:51:08PM +0200, Álvaro Herrera wrote: > On 2025-Apr-24, Bruce Momjian 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? And if > > so, do we think we are ever going to have a storage-format-changing > > release where pg_upgrade cannot be used? > > Peter E posted a patch that allowed pg_upgrade to migrate (rewrite) > files from non-checksummed to checksummed, but he appears to have given > up on it for this release given an apparent lack of interest. > https://postgr.es/m/57957aca-3eae-4106-afb2-3008122b9950@eisentraut.org Yeah, I saw that, and I think we could do something similar for TDE if we ever had it. I think we are suggesting people just do offline addition of checksums rather than trying to do something fancy with pg_upgrade. -- 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.