Azure PostgreSQL Flexible Server stuck in Dropping state; delete returns ResourceNotFound but resource remains

Question

We created an Azure Database for PostgreSQL Flexible Server using Bicep-based infrastructure-as-code scripts.

We later attempted to remove the PostgreSQL estate using our cleanup script:

pwsh .\IAC\Infra\Databases\PostgreSQL\remove-postgresql-estate.ps1 `

-SubscriptionId "<subscription-id>" `

-ResourceGroupName "<resource-group>" `

-PostgreSQLServerName "<server-name>" `

-KeyVaultName "<key-vault-name>" `

-DeletePrivateDnsZone `

-Confirm:$false

During the cleanup/delete operation, the PowerShell session/window was terminated before the operation completed.

Since then, the PostgreSQL Flexible Server has been stuck in a partial deletion state. It still appears in Azure Portal, Azure Resource Graph, and az postgres flexible-server list with state Dropping.

However, all delete attempts now return ResourceNotFound.

We have tried the following recovery/delete approaches:

1. Standard PostgreSQL Flexible Server delete:

az postgres flexible-server delete `

--resource-group "<resource-group>" `

--name "<server-name>" `

--yes

Result:

ResourceNotFound

2. Direct ARM REST delete:

az rest --method delete `

--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DBforPostgreSQL/flexibleServers/<server-name>?api-version=2023-06-01-preview"

Result:

ResourceNotFound

3. Generic ARM resource delete:

az resource delete `

--ids "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DBforPostgreSQL/flexibleServers/<server-name>"

Result:

ResourceNotFound

4. Redeployment reconciliation attempt:

We attempted to redeploy the same server name using the same Bicep/IAC deployment path, hoping Azure would reconcile the stuck Dropping state.

Result:

Deployment failed with ServerNameAlreadyExists.

The resource name still appears to be reserved, but delete operations cannot find the resource.

The stuck PostgreSQL Flexible Server also appears to be blocking cleanup of the delegated VNet subnet. The subnet still has a PostgreSQL service association link with linkedResourceType Microsoft.DBforPostgreSQL/flexibleServers, and VNet deletion fails because the subnet is still marked as in use.

Request:

Please advise how we can request or perform a backend cleanup of the stuck PostgreSQL Flexible Server metadata/name reservation and release the associated subnet service association link.

We do not need the PostgreSQL server recovered. We need the stuck resource fully removed so the remaining network resources can also be deleted cleanly and no further costs are charged to the subscription.

Answer 1

Hi @DJJ

Our engineering (PG) team has completed a backend validation and confirmed that the PostgreSQL Flexible Server was in a “tombstoned” state. This typically occurs when a delete operation is interrupted mid-way, leaving residual metadata (such as name reservation and subnet associations) even though the resource itself is no longer fully active.

The PG team has now completed the backend cleanup and fully removed the server metadata, including the associated tombstoned state.

Please let us know if you have any questions or concerns.

Answer 2

thanks, Manoj, answers along with fuller details anout the issue have been provided in the private message