Обсуждение: Direct Major Upgrade (13.7 → 17.6) with pg_upgrade: Clarifying the need for Intermediate Minor Fixes/Scripts

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

Hi Greg,
Much appreciated for the clear confirmation! It’s great to know that
`pg_upgrade` takes care of all structural changes, and that the
remaining "extra works" are indeed a rare manual check. I will follow
your advice and use common sense during the final review. Thanks for
the guidance and the reassurance.


On Wed, Oct 1, 2025 at 6:27 PM Greg Sabino Mullane <htamfids@gmail.com> wrote:
>
> On Wed, Oct 1, 2025 at 3:47 AM Vu Le (JData - HN) <dba4@jprotech.com.vn> wrote:
>>
>> My question is: When performing a direct jump from 13.7 to 17.6 using pg_upgrade, do I need to manually identify and
executethe cumulative extra works/fixes from ALL the skipped intermediate versions (13.8, 13.9, 14.x, 15.x, 16.x)? 
>
>
> Yes. Although with common sense, e.g. no need to reindex something twice.
>
>> Is there an official best practice document that clarifies how
>> pg_upgrade handles these "extra works" from skipped minor releases?
>
>
> These are not handled by pg_upgrade, hence the "extra". As you noted above, it's a manual step of reading the release
notesand taking steps depending on your particular database. Keep in mind, these steps are very rare. 
>
>> Does pg_upgrade implicitly incorporate all necessary structural fixes from the minor versions between 13.7 and 17.6?
>
>
> Yes
>
>>
>> Has anyone in the community performed a similar large jump and found unexpected issues due to skipping these
intermediatemanual steps? 
>
>
> I've jumped many versions, many times, for many clients. Just follow the recommended steps and all will be well.
>
> Cheers,
> Greg
>
> --
> Crunchy Data - https://www.crunchydata.com
> Enterprise Postgres Software Products & Tech Support
>


--
Best Regards,

Miles Le (Mr.)