Hi pgsql-general community,
I am planning a significant major version upgrade for a large-scale
PostgreSQL production environment, currently running PostgreSQL 13.7.
Our target is the latest major version, 17.6, utilizing the pg_upgrade
tool.
My core question revolves around the recommended Extra Works/Manual
Fixes from the intermediate minor and major versions.
*** THE PROBLEM / MY CONCERN
I've been reviewing various minor release notes and community advice.
It is common to see specific instructions for manual steps in certain
minor versions, such as:
- REINDEX requirements for specific index types.
- DROP/CREATE operations.
- Executing specialized SQL scripts (e.g., fix-CVE-2024-4317.sql in
some intermediate versions) to address data corruption or security
fixes that cannot be automatically handled by standard upgrades.
My question is: When performing a direct jump from 13.7 to 17.6 using
pg_upgrade, do I need to manually identify and execute the cumulative
extra works/fixes from ALL the skipped intermediate versions (13.8,
13.9, 14.x, 15.x, 16.x)?
*** STEPS TAKEN SO FAR
- Environment: Production (High Traffic, Large Data Volume).
- Method: Planning to use pg_upgrade.
- Testing: I have successfully performed the direct upgrade (13.7 ->
17.6) in our UAT/Dev environment. Functionality appears normal, but my
customer's self-built UAT/Dev environment is known not to perfectly
replicate 100% of our Production behavior, hence my caution.
*** ASK FOR BEST PRACTICES
Is there an official best practice document that clarifies how
pg_upgrade handles these "extra works" from skipped minor releases?
Does pg_upgrade implicitly incorporate all necessary structural fixes
from the minor versions between 13.7 and 17.6?
Has anyone in the community performed a similar large jump and found
unexpected issues due to skipping these intermediate manual steps?
Any guidance on this significant upgrade path would be highly appreciated.
Thank you in advance for your time and expertise.
--
Best Regards,
Miles Le (Mr.)
