Repository navigation
[Bug]: Database finalizer removal slow when deleting namespace due to exponential backoff #9554
Description
Is there an existing issue already for this bug?
- I have searched for an existing issue, and could not find anything. I believe this is a new bug.
I have read the troubleshooting guide
- I have read the troubleshooting guide and I think this is a new bug.
I am running a supported version of CloudNativePG
- I have read the troubleshooting guide and I think this is a new bug.
Contact Details
No response
Version
trunk (main)
What version of Kubernetes are you using?
1.34
What is your Kubernetes environment?
Self-managed: kind (evaluation)
How did you install the operator?
YAML manifest
What happened?
The E2E test Declarative database management / will not prevent the deletion of the namespace with lagging finalizers fails intermittently with a timeout.
The reason is that when a cluster has DeletionTimestamp != nil, the controller still attempts regular reconciliation instead of immediately entering the deletion path. This reconciliation causes failures when trying to create resources in a terminating namespace, resulting in an exponential backoff that delays finalizer removal beyond the test timeout.
The problem self-corrects eventually, but is visible to the user as an excessively slow namespace deletion.
Ideal continuation fo the work done in #9430
Cluster resource
N/ARelevant log output
See https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/20419155679Code of Conduct
- I agree to follow this project's Code of Conduct
Reacted by dosubot
Activity
dosubot commentedon Dec 22, 2025
Your bug report matches a recently fixed issue: errors during finalizer removal were being logged but not returned, causing orphaned database finalizers and slow namespace deletion. This was tracked in issue #9430 and fixed by PR #9431, which ensures errors are properly returned so reconciliation is retried and finalizers are removed as expected.
The relevant code for finalizer handling is in
internal/management/controller/finalizers.go, and the Database controller now immediately exits reconciliation ifDeletionTimestampis set, otherwise it continues normal logic and requeues after a fixed interval (source). The exponential backoff you observed is from controller-runtime's default retry behavior when reconciliation fails, not explicit logic in the finalizer code.If you're running the latest main branch after PR #9431, this specific bug should be resolved. If you still see delays, it may be due to other errors during deletion in a terminating namespace. Let me know if you need help troubleshooting further or want to dig into edge cases.
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
fix: enter deletion path immediately when cluster is being deleted
fix: enter deletion path immediately when cluster is being deleted (#…
fix: enter deletion path immediately when cluster is being deleted (#…
fix: enter deletion path immediately when cluster is being deleted (#…
fix: enter deletion path immediately when cluster is being deleted (c…
fix: enter deletion path immediately when cluster is being deleted (#…