fix(backup): use instance session ID to detect instance manager restarts - #9370

…rts (#9370)

This fix addresses an issue where backups would hang indefinitely during
operator releases. When the operator and barman plugin were updated
simultaneously, the backup goroutine running in the instance manager
would be killed (due to the instance manager binary being replaced via
exec()), but the operator would still think the backup was running
because the container ID hadn't changed.

The fix introduces a deterministic mechanism to detect instance manager
restarts by tracking the SessionID

Signed-off-by: Armando Ruocco <[email protected]>
Signed-off-by: Marco Nenciarini <[email protected]>
Co-authored-by: Marco Nenciarini <[email protected]>
(cherry picked from commit 102d785)

…rts (#9370)

This fix addresses an issue where backups would hang indefinitely during
operator releases. When the operator and barman plugin were updated
simultaneously, the backup goroutine running in the instance manager
would be killed (due to the instance manager binary being replaced via
exec()), but the operator would still think the backup was running
because the container ID hadn't changed.

The fix introduces a deterministic mechanism to detect instance manager
restarts by tracking the SessionID

Signed-off-by: Armando Ruocco <[email protected]>
Signed-off-by: Marco Nenciarini <[email protected]>
Co-authored-by: Marco Nenciarini <[email protected]>
(cherry picked from commit 102d785)

##### [\`v1.28.1\`](https://github.com/cloudnative-pg/cloudnative-pg/releases/tag/v1.28.1)

**Release date:** Feb 5, 2026

##### Enhancements

- Added support for Azure's `DefaultAzureCredential` authentication mechanism for backup and recovery operations. This can be enabled by setting `azureCredentials.useDefaultAzureCredentials: true` in the backup configuration, simplifying authentication in Azure environments without requiring explicit storage account keys or SAS tokens. ([#9468](cloudnative-pg/cloudnative-pg#9468)) <!-- 1.27 1.25 -->

##### Fixes

- Fixed validation of PostgreSQL extension names containing underscores (e.g., `pg_partman`, `pg_ivm`). Extension names with underscores are automatically sanitized to use hyphens for Kubernetes volume names while preserving the original name in mount paths. Webhook validation prevents naming conflicts after sanitization. Contributed by [@shusaan](https://github.com/shusaan). ([#9386](cloudnative-pg/cloudnative-pg#9386)) <!-- 1.27 -->

- Fixed a critical issue where the `TimelineID` in the cluster status was not reset to 1 after a major version upgrade. Because `pg_upgrade` initializes a new timeline, keeping the old ID (e.g., timeline 2) caused replicas to attempt to restore incompatible history files from object storage, leading to fatal "requested timeline is not a child of this server's history" errors. ([#9830](cloudnative-pg/cloudnative-pg#9830)) <!-- 1.27 -->

- Fixed an issue where stale TLS status fields in the `Pooler` were not cleared after being removed from the specification. This was particularly critical when upgrading to v1.28.0, where the `ServerTLS` field was repurposed, causing PgBouncer to use incorrect certificates and resulting in "unsupported certificate" errors that blocked all application connectivity. The operator now explicitly clears `ServerCA`, `ClientCA`, `ClientTLS`, and `ServerTLS` status fields when they are no longer configured. ([#9397](cloudnative-pg/cloudnative-pg#9397))

- Fixed a bug where replicas could enter a crash-loop by attempting to download timeline history files from future timelines. This occurred when stale files remained in the WAL archive from a previous cluster life, and replicas would incorrectly try to fetch them during recovery. ([#9650](cloudnative-pg/cloudnative-pg#9650)) <!-- 1.27 1.25 -->

- Fixed a race condition in `replica_cluster` setups during designated primary transitions, preventing transient "no primary" states in the replica cluster. ([#9601](cloudnative-pg/cloudnative-pg#9601)) <!-- 1.27 1.25 -->

- The backup controller now uses the unique instance session ID to detect instance manager restarts. This prevents the operator from incorrectly assuming a backup is still progressing if the underlying container has crashed and restarted, which previously led to orphaned backup objects. ([#9370](cloudnative-pg/cloudnative-pg#9370)) <!-- 1.27 -->

- Fixed a validation gap in Azure object store configurations where the `storageAccount` was not required when using explicit credentials (such as a storage key or SAS token). The operator now enforces that a storage account name is provided in these cases and that `connectionString` is mutually exclusive with other authentication parameters. ([#9604](cloudnative-pg/cloudnative-pg#9604)) <!-- 1.27 1.25 -->

- Optimized the deletion path so the operator begins cleaning up resources immediately when a cluster is marked for deletion. This significantly reduces the time a cluster remains in `Terminating` status while waiting for internal reconciliation loops. ([#9555](cloudnative-pg/cloudnative-pg#9555)) <!-- 1.27 1.25 -->

- Fixed an issue where replication slots were not properly dropped from replicas when the feature was disabled or the cluster was reconfigured. This ensures that unused slots do not cause WAL build-up on the primary. ([#9381](cloudnative-pg/cloudnative-pg#9381)) <!-- 1.27 1.25 -->

- Fixed an issue where `imagePullSecrets` were not added to the `ServiceAccount` created for the `Pooler`. Previously, these secrets were applied to the Deployment but not the SA, which caused image pull failures in restricted environments using certain security policies. ([#9427](cloudnative-pg/cloudnative-pg#9427)) <!-- 1.27 1.25 -->

- Added a check to verify ownership before the operator deletes a `PodMonitor`. This prevents the operator from accidentally deleting manually managed monitoring resources that happen to share a name with expected CNPG resources. Contributed by [@juliamertz](https://github.com/juliamertz). ([#9340](cloudnative-pg/cloudnative-pg#9340)) <!-- 1.27 1.25 -->

- Fixed a bug where `pg_stat_archiver` metrics would continue to report stale data on standby instances after a switchover. The exporter now skips these metrics on standbys, as PostgreSQL only provides valid archiver stats on the primary. ([#9411](cloudnative-pg/cloudnative-pg#9411)) <!-- 1.27 1.25 -->

- Clarified the interpretation of timestamp formats for recovery `targetTime`. Timestamps provided without an explicit timezone are now consistently interpreted as UTC. Contributed by [@pchovelon](https://github.com/pchovelon). ([#8937](cloudnative-pg/cloudnative-pg#8937)) <!-- 1.27 1.25 -->

- Fixed backup status updates to prevent "resource has been modified" errors during concurrent updates. ([#9551](cloudnative-pg/cloudnative-pg#9551)) <!-- 1.27 1.25 -->

- Fixed event reporting to use the correct pod name when a backup pod is not found. ([#9552](cloudnative-pg/cloudnative-pg#9552)) <!-- 1.27 1.25 -->

- Improved performance of scheduled backup operations for clusters with a very high number of historical backups. ([#9489](cloudnative-pg/cloudnative-pg#9489)) <!-- 1.27 1.25 -->

- Fixed error handling when removing finalizers on `Database` objects. ([#9431](cloudnative-pg/cloudnative-pg#9431)) <!-- 1.27 1.25 -->

- `cnpg` plugin:

  - Updated the `status` command to display "Disabled" when the `skipWalArchiving` annotation is present on a cluster. This replaces confusing "starting up" or "unknown" states when WAL archiving is intentionally bypassed. ([#9709](cloudnative-pg/cloudnative-pg#9709)) <!-- 1.27 1.25 -->

  - Fixed the `logs --follow` command to continue polling for new pods instead of exiting prematurely when all current log streams complete. ([#9599](cloudnative-pg/cloudnative-pg#9599)) <!-- 1.27 1.25 -->

##### [\`v1.28.1\`](https://github.com/cloudnative-pg/cloudnative-pg/releases/tag/v1.28.1)

**Release date:** Feb 5, 2026

##### Enhancements

- Added support for Azure's `DefaultAzureCredential` authentication mechanism for backup and recovery operations. This can be enabled by setting `azureCredentials.useDefaultAzureCredentials: true` in the backup configuration, simplifying authentication in Azure environments without requiring explicit storage account keys or SAS tokens. ([#9468](cloudnative-pg/cloudnative-pg#9468)) <!-- 1.27 1.25 -->

##### Fixes

- Fixed validation of PostgreSQL extension names containing underscores (e.g., `pg_partman`, `pg_ivm`). Extension names with underscores are automatically sanitized to use hyphens for Kubernetes volume names while preserving the original name in mount paths. Webhook validation prevents naming conflicts after sanitization. Contributed by [@shusaan](https://github.com/shusaan). ([#9386](cloudnative-pg/cloudnative-pg#9386)) <!-- 1.27 -->

- Fixed a critical issue where the `TimelineID` in the cluster status was not reset to 1 after a major version upgrade. Because `pg_upgrade` initializes a new timeline, keeping the old ID (e.g., timeline 2) caused replicas to attempt to restore incompatible history files from object storage, leading to fatal "requested timeline is not a child of this server's history" errors. ([#9830](cloudnative-pg/cloudnative-pg#9830)) <!-- 1.27 -->

- Fixed an issue where stale TLS status fields in the `Pooler` were not cleared after being removed from the specification. This was particularly critical when upgrading to v1.28.0, where the `ServerTLS` field was repurposed, causing PgBouncer to use incorrect certificates and resulting in "unsupported certificate" errors that blocked all application connectivity. The operator now explicitly clears `ServerCA`, `ClientCA`, `ClientTLS`, and `ServerTLS` status fields when they are no longer configured. ([#9397](cloudnative-pg/cloudnative-pg#9397))

- Fixed a bug where replicas could enter a crash-loop by attempting to download timeline history files from future timelines. This occurred when stale files remained in the WAL archive from a previous cluster life, and replicas would incorrectly try to fetch them during recovery. ([#9650](cloudnative-pg/cloudnative-pg#9650)) <!-- 1.27 1.25 -->

- Fixed a race condition in `replica_cluster` setups during designated primary transitions, preventing transient "no primary" states in the replica cluster. ([#9601](cloudnative-pg/cloudnative-pg#9601)) <!-- 1.27 1.25 -->

- The backup controller now uses the unique instance session ID to detect instance manager restarts. This prevents the operator from incorrectly assuming a backup is still progressing if the underlying container has crashed and restarted, which previously led to orphaned backup objects. ([#9370](cloudnative-pg/cloudnative-pg#9370)) <!-- 1.27 -->

- Fixed a validation gap in Azure object store configurations where the `storageAccount` was not required when using explicit credentials (such as a storage key or SAS token). The operator now enforces that a storage account name is provided in these cases and that `connectionString` is mutually exclusive with other authentication parameters. ([#9604](cloudnative-pg/cloudnative-pg#9604)) <!-- 1.27 1.25 -->

- Optimized the deletion path so the operator begins cleaning up resources immediately when a cluster is marked for deletion. This significantly reduces the time a cluster remains in `Terminating` status while waiting for internal reconciliation loops. ([#9555](cloudnative-pg/cloudnative-pg#9555)) <!-- 1.27 1.25 -->

- Fixed an issue where replication slots were not properly dropped from replicas when the feature was disabled or the cluster was reconfigured. This ensures that unused slots do not cause WAL build-up on the primary. ([#9381](cloudnative-pg/cloudnative-pg#9381)) <!-- 1.27 1.25 -->

- Fixed an issue where `imagePullSecrets` were not added to the `ServiceAccount` created for the `Pooler`. Previously, these secrets were applied to the Deployment but not the SA, which caused image pull failures in restricted environments using certain security policies. ([#9427](cloudnative-pg/cloudnative-pg#9427)) <!-- 1.27 1.25 -->

- Added a check to verify ownership before the operator deletes a `PodMonitor`. This prevents the operator from accidentally deleting manually managed monitoring resources that happen to share a name with expected CNPG resources. Contributed by [@juliamertz](https://github.com/juliamertz). ([#9340](cloudnative-pg/cloudnative-pg#9340)) <!-- 1.27 1.25 -->

- Fixed a bug where `pg_stat_archiver` metrics would continue to report stale data on standby instances after a switchover. The exporter now skips these metrics on standbys, as PostgreSQL only provides valid archiver stats on the primary. ([#9411](cloudnative-pg/cloudnative-pg#9411)) <!-- 1.27 1.25 -->

- Clarified the interpretation of timestamp formats for recovery `targetTime`. Timestamps provided without an explicit timezone are now consistently interpreted as UTC. Contributed by [@pchovelon](https://github.com/pchovelon). ([#8937](cloudnative-pg/cloudnative-pg#8937)) <!-- 1.27 1.25 -->

- Fixed backup status updates to prevent "resource has been modified" errors during concurrent updates. ([#9551](cloudnative-pg/cloudnative-pg#9551)) <!-- 1.27 1.25 -->

- Fixed event reporting to use the correct pod name when a backup pod is not found. ([#9552](cloudnative-pg/cloudnative-pg#9552)) <!-- 1.27 1.25 -->

- Improved performance of scheduled backup operations for clusters with a very high number of historical backups. ([#9489](cloudnative-pg/cloudnative-pg#9489)) <!-- 1.27 1.25 -->

- Fixed error handling when removing finalizers on `Database` objects. ([#9431](cloudnative-pg/cloudnative-pg#9431)) <!-- 1.27 1.25 -->

- `cnpg` plugin:

  - Updated the `status` command to display "Disabled" when the `skipWalArchiving` annotation is present on a cluster. This replaces confusing "starting up" or "unknown" states when WAL archiving is intentionally bypassed. ([#9709](cloudnative-pg/cloudnative-pg#9709)) <!-- 1.27 1.25 -->

  - Fixed the `logs --follow` command to continue polling for new pods instead of exiting prematurely when all current log streams complete. ([#9599](cloudnative-pg/cloudnative-pg#9599)) <!-- 1.27 1.25 -->

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives: the controller scheduled no requeue after starting
the backup, and the watch on clusters could not reschedule it either, so
the backup stayed in the "started" phase forever and the session ID
check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed.

The cluster-to-backup mapper also enqueued the running backups of every
cluster in the namespace except the one that changed; invert that
condition. The predicate gating those events only matched clusters with
an in-core backup section, which clusters backed up through a CNPG-I
plugin do not have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives and nothing reschedules the backup: the controller
scheduled no requeue after starting it, and the watch on clusters could
not re-enqueue it either, so the backup stayed in the "started" phase
and the session ID check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed. The backup is passed to startBackupManagedByInstance by
pointer so the phase transition stays visible to that check.

The cluster-to-backup mapper also enqueued the running backups of every
cluster in the namespace except the one that changed; invert that
condition, and include "started" backups in the lookup so the cluster
event caused by the failure that orphaned a backup is the earliest
chance to detect it. The predicate gating those events only matched
clusters with an in-core backup section, which clusters backed up
through a CNPG-I plugin do not have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives and nothing reschedules the backup: the controller
scheduled no requeue after starting it, and the watch on clusters could
not re-enqueue it either, so the backup stayed in the "started" phase
and the session ID check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed. The backup is passed to startBackupManagedByInstance by
pointer so the phase transition stays visible to that check.

The cluster-to-backup mapper also enqueued the running backups of every
cluster in the namespace except the one that changed; invert that
condition, and include "started" backups in the lookup so the cluster
event caused by the failure that orphaned a backup is the earliest
chance to detect it. The predicate gating those events only matched
clusters with an in-core backup section, which clusters backed up
through a CNPG-I plugin do not have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives and nothing reschedules the backup: the controller
scheduled no requeue after starting it, and the watch on clusters could
not re-enqueue it either, so the backup stayed in the "started" phase
and the session ID check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed. The backup is passed to startBackupManagedByInstance by
pointer so the phase transition stays visible to that check.

The cluster-to-backup mapper also enqueued the running backups of every
cluster in the namespace except the one that changed; invert that
condition, and include "started" backups in the lookup so the cluster
event caused by the failure that orphaned a backup is the earliest
chance to detect it. The predicate gating those events only matched
clusters with an in-core backup section, which clusters backed up
through a CNPG-I plugin do not have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives and nothing reschedules the backup: the controller
scheduled no requeue after starting it, and the watch on clusters could
not re-enqueue it either, so the backup stayed in the "started" phase
and the session ID check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed. The backup is passed to startBackupManagedByInstance by
pointer so the phase transition stays visible to that check.

The cluster-to-backup mapper also enqueued the running backups of every
cluster in the namespace except the one that changed; invert that
condition, and include "started" backups in the lookup so the cluster
event caused by the failure that orphaned a backup is the earliest
chance to detect it. The predicate gating those events only matched
clusters with an in-core backup section, which clusters backed up
through a CNPG-I plugin do not have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives and nothing reschedules the backup: the controller
scheduled no requeue after starting it, and the watch on clusters could
not re-enqueue it either, so the backup stayed in the "started" phase
and the session ID check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed. The backup is passed to startBackupManagedByInstance by
pointer so the phase transition stays visible to that check.

The cluster-to-backup mapper also enqueued the running backups of every
cluster in the namespace except the one that changed; invert that
condition, and include "started" backups in the lookup so the cluster
event caused by the failure that orphaned a backup is the earliest
chance to detect it. The predicate gating those events only matched
clusters with an in-core backup section, which clusters backed up
through a CNPG-I plugin do not have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives and nothing reschedules the backup: the controller
scheduled no requeue after starting it, and the watch on clusters could
not re-enqueue it either, so the backup stayed in the "started" phase
and the session ID check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed. The backup is passed to startBackupManagedByInstance by
pointer so the phase transition stays visible to that check.

The cluster-to-backup mapper also enqueued the running backups of every
cluster in the namespace except the one that changed; invert that
condition, and include "started" backups in the lookup so the cluster
event caused by the failure that orphaned a backup is the earliest
chance to detect it. The predicate gating those events only matched
clusters with an in-core backup section, which clusters backed up
through a CNPG-I plugin do not have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives and nothing reschedules the backup: the controller
scheduled no requeue after starting it, and the watch on clusters could
not re-enqueue it either, so the backup stayed in the "started" phase
and the session ID check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed. The backup is now passed to startBackupManagedByInstance by
pointer so the phase transition stays visible to that check.

The cluster-to-backup mapper, the other path that could have re-enqueued
the backup, had two further problems. It enqueued the running backups of
every cluster in the namespace except the one that actually changed, so
invert that condition; and it only considered "running" backups, so
include "started" ones too, since the cluster event from the failure
that orphaned the backup is the earliest chance to detect it. The
predicate gating those events only matched clusters with an in-core
backup section, which clusters backed up through a CNPG-I plugin do not
have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>
Signed-off-by: Marco Nenciarini <[email protected]>
Co-authored-by: Marco Nenciarini <[email protected]>

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives and nothing reschedules the backup: the controller
scheduled no requeue after starting it, and the watch on clusters could
not re-enqueue it either, so the backup stayed in the "started" phase
and the session ID check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed. The backup is now passed to startBackupManagedByInstance by
pointer so the phase transition stays visible to that check.

The cluster-to-backup mapper, the other path that could have re-enqueued
the backup, had two further problems. It enqueued the running backups of
every cluster in the namespace except the one that actually changed, so
invert that condition; and it only considered "running" backups, so
include "started" ones too, since the cluster event from the failure
that orphaned the backup is the earliest chance to detect it. The
predicate gating those events only matched clusters with an in-core
backup section, which clusters backed up through a CNPG-I plugin do not
have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>
Signed-off-by: Marco Nenciarini <[email protected]>
Co-authored-by: Marco Nenciarini <[email protected]>
(cherry picked from commit 6b916d0)

A backup in the "started" phase only moves forward through the status
updates of the instance manager that is running it. When that instance
manager is restarted before the backup reaches the "running" phase, for
example by the in-place upgrade that follows an operator upgrade, no
update ever arrives and nothing reschedules the backup: the controller
scheduled no requeue after starting it, and the watch on clusters could
not re-enqueue it either, so the backup stayed in the "started" phase
and the session ID check introduced by #9370 never had a chance to run.

Requeue the reconciliation while a backup is in the "started" phase so
the lost instance manager session is detected and the backup is marked
as failed. The backup is now passed to startBackupManagedByInstance by
pointer so the phase transition stays visible to that check.

The cluster-to-backup mapper, the other path that could have re-enqueued
the backup, had two further problems. It enqueued the running backups of
every cluster in the namespace except the one that actually changed, so
invert that condition; and it only considered "running" backups, so
include "started" ones too, since the cluster event from the failure
that orphaned the backup is the earliest chance to detect it. The
predicate gating those events only matched clusters with an in-core
backup section, which clusters backed up through a CNPG-I plugin do not
have; match those too.

Signed-off-by: Armando Ruocco <[email protected]>
Signed-off-by: Marco Nenciarini <[email protected]>
Co-authored-by: Marco Nenciarini <[email protected]>
(cherry picked from commit 6b916d0)