Repository navigation
[Bug]: Replication slots not cleaned up on replicas when both HA and synchronizeReplicas are disabled #9380
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?
User-defined replication slots are not cleaned up from replica pods when both replicationSlots.highAvailability.enabled and replicationSlots.synchronizeReplicas.enabled are disabled.
This is the root cause of the flaky E2E test in #8968, which was tentatively addressed in #8971 by increasing the timeout; however, the actual bug was not resolved.
Root Cause
When replication slots are disabled, the Replicator stops without performing cleanup:
if config == nil || !config.GetEnabled() {
ticker.Stop()
updateInterval = 0
continue // ← BUG: No cleanup happens
}When both features are disabled, config.GetEnabled() returns false, causing the loop to continue without calling sr.reconcile(). The cleanup logic in synchronizeReplicationSlots() is never executed.
Cluster resource
Relevant log output
No errors logged - the Replicator silently stops without cleanup.Code of Conduct
- I agree to follow this project's Code of Conduct
Reacted by dosubot
Activity
dosubot commentedon Dec 7, 2025
This is a new, previously undocumented bug: when both
replicationSlots.highAvailability.enabledandreplicationSlots.synchronizeReplicas.enabledare disabled, the Replicator process stops without performing cleanup, so user-defined replication slots are not removed from replicas. This is confirmed by the code ininternal/management/controller/slots/runner/runner.go, where the main loop exits early and never calls the cleanup logic insynchronizeReplicationSlotsif both features are disabled. As a result, slots linger on replicas, which explains the flaky E2E test in #8968. The recent PR #8971 only increased test timeouts and did not address the root cause—no merged PRs or issues currently fix this behavior. The expected cleanup (removal of slots when synchronization is disabled) is documented, but the implementation does not trigger it in this scenario, so manual cleanup or a code change is needed to resolve the issue source docs.To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
fix(slots): cleanup replication slots on replicas when features disabled
fix(slots): cleanup replication slots on replicas when features disab…
fix(slots): cleanup replication slots on replicas when features disab…
fix(slots): cleanup replication slots on replicas when features disab…
fix(slots): cleanup replication slots on replicas when features disab…
fix(slots): cleanup replication slots on replicas when features disab…