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.
/messages/by-id/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.
/messages/by-id/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.