Repository navigation
CatalogMaintenanceRunnable fails repeatedly on clusters without backup configuration #774
Description
Description
The CatalogMaintenanceRunnable is registered unconditionally on every instance, including replica clusters that have no backup configuration (no barmanObjectName parameter).
On these clusters, cycle() calls NewFromCluster(), which sets BarmanObjectName to an empty string. Then GetBarmanObjectKey() returns a NamespacedName with Name: "", and the Client.Get() call on line 92 fails with "resource name may not be empty".
This logs an error every 5 minutes indefinitely.
How to reproduce
- Create a replica cluster with the barman-cloud plugin enabled but no
barmanObjectNamein the plugin parameters (i.e., no backup configuration — only WAL restore from a source cluster). - Observe the sidecar logs:
Repeating every ~5 minutes.
{"level":"error","msg":"Retention policy enforcement failed","error":"resource name may not be empty"}
Suggested fix
Add an early return in cycle() when BarmanObjectName is empty:
func (c *CatalogMaintenanceRunnable) cycle(ctx context.Context) (time.Duration, error) {
var cluster cnpgv1.Cluster
if err := c.Client.Get(ctx, c.ClusterKey, &cluster); err != nil {
return 0, err
}
configuration := config.NewFromCluster(&cluster)
if configuration.BarmanObjectName == "" {
return 0, nil
}
// ... rest of the function
}Alternatively, don't register CatalogMaintenanceRunnable at all when there's no backup configuration. Note that the barman sidecar itself is still needed on replica clusters for WAL restore. Only the retention runnable is unnecessary.
However, not registering CatalogMaintenanceRunnable conditionally requires reading the cluster spec at sidecar startup to determine whether backup is configured, which adds complexity. The early return in cycle() is simpler and handles the case at runtime.
Activity
GabriFedi97 commentedon Apr 3, 2026
@daanvinken thanks for reporting this bug. While your proposals could technically work I believe there are few other things we should consider.
Replica Clusters have the ability to either restore WAL files from a source archive and to perform backups and WAL archiving to a target ObjectStore. Both operations are delegated to the same
plugin-barman-cloudsidecar container, which is configured via Lifecycle hook for Clusters having the plugin enabled for either ExternalClusters (for restores) or via the standard Plugin stanza (for backups).However, the maintenance task is meant to be performed only against the target ObjectStore for Backups and WAL archiving.
Beside ensuring the presence of the
configuration.BarmanObjectNameinfo, I think we should check if the plugin is enabled to perform Backups and WAL archiving first and proceeding only if this condition is verified and returning an error in case of missingBarmanObjectName.I would avoid omitting the registration of
CatalogMaintenanceRunnableif no backup configuration is present as, if added later, it would require a restart to be registered.fix: skip maintenance cycle when plugin is not enabled for backups (#826
chore(main): release 0.12.0 (#756)
chore(deps): update dependency cloudnative-pg/plugin-barman-cloud to …
chore(deps): update dependency cloudnative-pg/plugin-barman-cloud to …
chore(deps): update dependency https://github.com/cloudnative-pg/plug…