EDB CloudNativePG Cluster 1.28.5 release notes v1.30.1

Requires EPAS or PG Extended 16 or newer; the field is immutable after creation, since changing it would need re-encrypting existing data. Major upgrades now derive the key length from the old data directory instead of trusting the spec.

It was previously rejected by the validating webhook even though the operator does not manage it. Contributed by @Jamstah.

Useful with a custom authQuerySecret where the role to authenticate as differs from the one implied by the Secret. Contributed by @jonasbadstuebner.

Contributed by @AdzerKI (SHOW STATS).

Affected entries are now resolved and rejected/skipped consistently across admission, the major-upgrade job, and already-persisted Cluster specs. Contributed by @Anand-240.

Previously, an old primary whose PostgreSQL had become unresponsive was never shut down, so it could never rejoin the cluster as a replica of the new primary. The shutdown is now requested without blocking the reconciler, though demotion can still take up to a minute or more if PostgreSQL keeps ignoring shutdown signals.

A fenced instance kept reporting itself as healthy on its status endpoint even though its Pod was permanently not Ready, which blocked the readiness guard, the primary-election logic, and the Pod-reattachment gate from reacting to an unrelated failure elsewhere in the cluster, leaving it stalled until someone manually removed the fencing. All three now recognize and skip fenced instances.

While a failover was pending, the reconciler could skip checking whether it was ready to complete, or mistake the pending state for a missing Pod and reset the target primary back to the unhealthy one. It now keeps progressing a pending failover and completes it once the WAL receivers are down, rechecking quorum safety right before promoting in case it changed while waiting.

If the designated primary's Pod later disappeared from the status list, this could have led the operator to promote the wrong standby.

The request carried no explicit timeout, so pg_ctl fell back to its own implicit 60-second limit, and the instance manager, being PID 1 in the container, took PostgreSQL down mid-shutdown regardless of a larger configured stopDelay. The fast phase now waits for the full stopDelay instead.

Contributed by @evan314159.

Contributed by @GellertBabel.

ArgoCD foreground deletion) waiting for those resources to disappear. Contributed by @mjlshen.

Contributed by @HoniSanders.

Contributed by @andrew-farries.

Contributed by @Utkarsh-sharma47.

Contributed by @sharifmshaker.

Contributed by @daanvinken.