Azure Database for PostgreSQL Flexible Server major version upgrade failure

Tom A 0 Reputation points
2026-06-15T20:09:56.3533333+00:00

Upgrade failed and no useful error message:

Activity Log Error: ResourceOperationFailure InternalServerError "An unexpected error occurred while processing the request."

Validation Performed:

  • No read replicas
  • High Availability disabled
  • No replication slots
  • No publications
  • No subscriptions
  • No pg_cron jobs
  • Role validation query returns 0 rows
  • Invalid indexes count = 0
  • PostgreSQL version = 16.13
  • Extensions installed:
  • azure 1.1
  • pg_cron 1.6
  • pgaadauth 1.10
    • plpgsql 1.0
Azure Database for PostgreSQL
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. SAI JAGADEESH KUDIPUDI 3,550 Reputation points Microsoft External Staff Moderator
    2026-06-18T00:04:49.1866667+00:00

    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)

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

    Was this answer helpful?

    1 person found this answer helpful.

  2. AI answer

    2026-06-15T20:10:11.56+00:00

    The activity log error alone is too generic to identify the root cause. For Azure Database for PostgreSQL flexible server, in-place major version upgrades are blocked by specific precheck failures and configuration/extension limitations. The next step is to surface the detailed precheck/pg_upgrade output and then compare it against the documented blockers.

    Follow these steps to isolate the cause:

    1. Run Upgrade Validation Checks (Validate Only)
      • In the Azure portal, open the PostgreSQL flexible server.
      • Go to Overview → Upgrade.
      • Select the same target PostgreSQL major version that failed previously.
      • Select Validate Only and start validation.
      • Wait for completion and keep the validation status pane open.
      • This runs the same prechecks as the upgrade but without changing the server or causing downtime.
    2. Review validation results for blocking issues
      • After validation completes, review the results pane:
        • Look for any failed validation checks.
        • Each failed check includes an error description and remediation guidance.
      • Download the results as a .csv file for detailed review if needed. The CSV includes:
        • Validation check name
        • Validation result
        • Error details
        • Remediation recommendations
    3. Check detailed pg_upgrade / validation logs
      • Ensure Server logs are enabled on the server.
      • In the Azure portal, go to the PostgreSQL flexible server → Monitoring → Server logs.
      • Locate the generated pg_upgrade (or upgrade validation) log files from the failed attempt or from the validation run.
      • Download and inspect these logs; they contain the detailed error that caused the precheck or upgrade to fail.
    4. Compare findings with known upgrade limitations
      • From the validation/log output, check for any of the documented blockers, for example:
        • Unsupported server configurations (geo-replication, blocked ports 5432/6432, NSG rules affecting HA re-enable, logical replication slots, views depending on pg_stat_activity, SCRAM requirement when upgrading from PostgreSQL 11, etc.).
        • Extension limitations:
          • Some extensions are supported for use but block in-place major version upgrades and must be dropped before upgrade, then re-created if supported on the target version.
          • Non-persistent utility extensions (for example hypopg, pg_repack) must be dropped and re-created by design.
          • When upgrading to PostgreSQL 17 or later, certain extensions (for example age, azure_ai, hll, pg_diskann, pgrouting) are not supported and must be removed before upgrade.
      • If validation reports an unsupported extension, follow the remediation guidance (typically: drop the extension, perform the upgrade, then re-create it if supported on the target version).
    5. Re-run validation and then the upgrade
      • After fixing all reported blocking issues, re-run Validate Only to confirm a clean result (no blocking issues detected).
      • Once validation passes, run the actual major version upgrade again.

    If validation and logs show no blocking issues but the upgrade still fails with only InternalServerError, collect the validation CSV and pg_upgrade logs and open a support case, as the platform-side failure is not exposed in the generic activity log message.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.