Azure Database for PostgreSQL Flexible Server major version upgrade failure

Hi @Tom A ,

For Azure Database for PostgreSQL Flexible Server, a major version upgrade that fails with only a generic InternalServerError in the Activity Log usually needs a closer look at the upgrade pre-check/upgrade logs, because the real blocker is often an unsupported feature, extension issue, or a server configuration condition that the high-level error message doesn’t surface.

Based on the documentation, here’s the best troubleshooting path to share publicly.

What to check (in the Azure Portal / logs)

1. Enable/review the Major Version Upgrade logs
   • Go to your Flexible Server in the Azure portal.
   • Check Monitoring for Major Version Upgrade logs / PG_Upgrade_Logs (the link in the docs is “Major Version Upgrade logs”).
   • Look for the specific validation/precheck error that caused the failure (the Activity Log “unexpected error” is often just the wrapper).
2. Confirm the server has no unsupported upgrade blockers The in-place major version upgrade has several important limitations. Even if some validation items show “no issues” (like replicas, replication slots, publications, etc.), other items can still block the upgrade, especially around extensions and configuration. Common blockers called out in the docs include:
   • Unsupported extensions (certain ones must be removed before upgrading)
   • Logical replication objects (subscriptions/publishers) — the docs note these are unsupported during upgrade
   • “pg_settings pending restart” issues — if present, restart and retry
   • Unsupported pre-upgrade module config(for example, unsupported modules in shared_preload_libraries)
   • Tables with OIDs (for PostgreSQL 12+ upgrades)
   • 1. Extension-specific guidance (important for your case)

Your list shows installed extensions including:

• azure 1.1
• pg_cron 1.6
• pgaadauth 1.10

…and the docs note that some extensions are not supported for in-place major upgrades.

Action:

1. List all installed extensions**

   
    SELECT extname, extversion FROM pg_extension;
   
   

2. Compare them to the extension limitations for major version upgrades.
3. Drop any extensions that are unsupported for major upgrades, then retry.
4. After the upgrade completes successfully, reinstall the supported extensions as needed.

(If the precheck is failing because of an extension, it’s usually clearly called out in PG_Upgrade_Logs, which is why reviewing those logs is key.)

Check for pending restart parameters

If the upgrade pipeline sees pending restarts, it may fail precheck.

Run:

SELECT name, setting

FROM pg_settings

WHERE pending_restart IS TRUE;

If any rows show up, the docs recommend restarting the server and then retrying the upgrade.
If you had “resource/config” related validation failures

Even when the “postgres logical replication / replicas” validations are clean, the docs also call out:

• Insufficient resources (storage headroom, compute capacity)
• Background operations/transactions (can interfere)
• Capacity/region limitations (sometimes the portal upgrade option is affected by capacity)

Also, if the upgrade succeeds but performance changes appear afterward, the docs recommend running:

ANALYZE VERBOSE;

to refresh optimizer statistics.

How to proceed (suggested “next message” for the forum)

If you want a direct next step to try quickly:

• Open the server’s Major Version Upgrade logs / PG_Upgrade_Logs in the portal and paste the exact precheck/validation failure line here.
• In parallel, run the extension listing query above and confirm whether any extension is on the “not supported” list for major upgrades.

Once we know the exact precheck failure reason from the upgrade logs, the remediation is usually very specific (drop/recreate/remove/restart/change a parameter).

Follow-up questions (so we can pinpoint the blocker)

1. What is the target major version (what version did you upgrade to, not just “current version = 16.13”)?
2. In the Azure portal, what is the exact error in PG_Upgrade_Logs / Major Version Upgrade logs (the specific precheck failure message/code)?
3. Can you share the output of:

   
    SELECT extname, extversion FROM pg_extension;
   
   

4. Does this query return any rows?

   
    SELECT name, setting
   
    FROM pg_settings
   
    WHERE pending_restart IS TRUE;
   
   

5. Are there any logical replication objects (publications/subscriptions) or roles involved beyond what your validation listed (and do you have any non-superuser-owned subscriptions, if subscriptions exist)?
6. Do you have any special server settings / shared_preload_libraries entries that might include modules flagged as unsupported in the docs?

References (relevant documentation)

• Major Version Upgrades (overview, steps, logs, limitations):
• How to perform an in-place major version upgrade (portal/CLI):
• Major Version Upgrade logs:
• Extension limitations for major version upgrades:
• (Portal/irreversibility/PITR note):

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.