Share via

Major version upgrade (14 to 18) hangs indefinitely - dblink_fdw / PgBouncer foreign server blocking pg_upgrade

Bob Binckes 25 Reputation points
2026-04-01T14:31:13.1433333+00:00

Problem

In-place major version upgrade from PostgreSQL 14.20 to 18 on Azure Database for PostgreSQL Flexible Server hangs indefinitely. The upgrade never begins — the server stays online at version 14 and is never taken offline for pg_upgrade.

Region: West US 2 SKU: Standard_D2ds_v4 (General Purpose) Current Version: PostgreSQL 14.20 Target Version: PostgreSQL 18 PgBouncer: Enabled (built-in)

Root Cause (suspected)

The postgres database contains Azure-managed objects created by the built-in PgBouncer feature that appear to silently block the pg_upgrade precheck:

SELECT fdwname, fdwowner::regrole FROM pg_foreign_data_wrapper;

The upgrade documentation states that postgres_fdw blocks upgrades. We believe dblink_fdw is being treated the same way by pg_upgrade. Since all these objects are owned by azuresu, we cannot drop them as azure_pg_admin users.

What we tried

Azure CLI (az postgres flexible-server upgrade --version 18 --yes): Hangs indefinitely. Debug logs (--debug) show two GET requests to the server resource but the PUT/PATCH to trigger the upgrade is never sent. CLI version 2.84.0.

Azure Portal (Overview > Upgrade > version 18): Shows "Deployment is in progress" but the server remains on version 14, stays online, and never begins the actual pg_upgrade. Ran for 80+ minutes with no progress before we cancelled.

REST API (PATCH to flexibleServers endpoint with {"properties":{"version":"18"}}): Returns an operation ID but the server version never changes.

Disabled PgBouncer (pgbouncer.enabled = FALSE) before attempting upgrade: The parameter changes but the dblink_fdw, pgbouncer foreign server, and all pgbouncer views remain in the postgres database. Upgrade still hangs.

Manual DROP: Cannot drop any of these objects — all owned by azuresu:

ERROR: must be owner of schema pgbouncer

Server configuration

Storage: 128 GB (8.4% used) — well above the 10-20% free space requirement

No read replicas

No high availability

No logical replication slots

No event triggers

No blocking extensions (no timescaledb, postgres_fdw, age, azure_ai, hll, pg_diskann, pgrouting)

Extensions in user databases: PostGIS 3.5.2, uuid-ossp 1.1 (both supported on PG 18)

23 databases including 2 custom template databases (unlocked before upgrade attempt)

Question

How can we perform the major version upgrade when dblink_fdw and the pgbouncer foreign server (both owned by azuresu) are blocking pg_upgrade? Is there a workaround, or does Azure need to remove these objects on the backend?

This affects our upgrade path for Dev, Test, and Prod environments — all have PgBouncer enabled.

Problem

In-place major version upgrade from PostgreSQL 14.20 to 18 on Azure Database for PostgreSQL Flexible Server hangs indefinitely. The upgrade never begins — the server stays online at version 14 and is never taken offline for pg_upgrade.

Region: West US 2 SKU: Standard_D2ds_v4 (General Purpose) Current Version: PostgreSQL 14.20 Target Version: PostgreSQL 18 PgBouncer: Enabled (built-in)

Root Cause (suspected)

The postgres database contains Azure-managed objects created by the built-in PgBouncer feature that appear to silently block the pg_upgrade precheck:

SELECT fdwname, fdwowner::regrole FROM pg_foreign_data_wrapper;

The upgrade documentation states that postgres_fdw blocks upgrades. We believe dblink_fdw is being treated the same way by pg_upgrade. Since all these objects are owned by azuresu, we cannot drop them as azure_pg_admin users.

What we tried

Azure CLI (az postgres flexible-server upgrade --version 18 --yes): Hangs indefinitely. Debug logs (--debug) show two GET requests to the server resource but the PUT/PATCH to trigger the upgrade is never sent. CLI version 2.84.0.

Azure Portal (Overview > Upgrade > version 18): Shows "Deployment is in progress" but the server remains on version 14, stays online, and never begins the actual pg_upgrade. Ran for 80+ minutes with no progress before we cancelled.

REST API (PATCH to flexibleServers endpoint with {"properties":{"version":"18"}}): Returns an operation ID but the server version never changes.

Disabled PgBouncer (pgbouncer.enabled = FALSE) before attempting upgrade: The parameter changes but the dblink_fdw, pgbouncer foreign server, and all pgbouncer views remain in the postgres database. Upgrade still hangs.

Manual DROP: Cannot drop any of these objects — all owned by azuresu:

ERROR: must be owner of schema pgbouncer

Server configuration

Storage: 128 GB (8.4% used) — well above the 10-20% free space requirement

No read replicas

No high availability

No logical replication slots

No event triggers

No blocking extensions (no timescaledb, postgres_fdw, age, azure_ai, hll, pg_diskann, pgrouting)

Extensions in user databases: PostGIS 3.5.2, uuid-ossp 1.1 (both supported on PG 18)

23 databases including 2 custom template databases (unlocked before upgrade attempt)

Question

How can we perform the major version upgrade when dblink_fdw and the pgbouncer foreign server (both owned by azuresu) are blocking pg_upgrade? Is there a workaround, or does Azure need to remove these objects on the backend?

Azure Database for PostgreSQL
0 comments
Answer accepted by question author
  1. Manoj Kumar Boyini 11,280 Reputation points Microsoft External Staff Moderator
    2026-04-01T15:41:20.44+00:00

    Hi Bob Binckes

    Review all prerequisites, supported extensions, and known limitations for major version upgrades:

    Major Version Upgrades – Azure Database for PostgreSQL https://learn.microsoft.com/azure/postgresql/flexible-server/how-to-upgrade-postgresql-major-version

    Disable PgBouncer by setting the following parameter:

    pgbouncer.enabled = false

    Then restart the PostgreSQL server to ensure the change takes effect.

    After the restart, check whether the dblink extension exists and attempt to remove it:

    DROP EXTENSION dblink CASCADE;

    This drops dblink_fdw, the PgBouncer foreign server, and related views, which can block the pg_upgrade precheck.

    Validate extensions in the postgres database
    Ensure all extensions including those in the postgres database are upgraded to versions supported by the target PostgreSQL major version. In this case, upgrading PostGIS from 3.2.x to 3.6.x in the postgres database was required. An outdated PostGIS version can cause the upgrade to stall or appear to hang.

    Run the major version upgrade Once:

    PgBouncer is disabled
    dblink / PgBouncer objects are removed
    All extensions (including in postgres) are on supported versions

    the major version upgrade should proceed successfully. PgBouncer can be re‑enabled after completion.

    Hope this helps, Please let us know if you have any questions and concerns.

    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Haris Catakovic 0 Reputation points Microsoft Employee
    2026-04-03T00:51:03.4666667+00:00

    @Bob Binckes , if you still hit the same wall after following Manoj's steps above, I'd recommend filing an Azure support ticket (Sev B or higher). This likely requires backend intervention where Azure engineering may need to clean up the azuresu-owned FDW objects before the upgrade precheck will pass.

    In your ticket, I'd include the output of a SELECT fdwname, fdwowner::regrole FROM pg_foreign_data_wrapper;, the CLI --debug logs showing the PUT never fires, and the fact that disabling PgBouncer leaves the objects orphaned. That should help short-circuit L1 triage.

    0 comments

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.