EDB CloudNativePG Cluster 1.29.0 release notes v1.29.0

extended the ImageCatalogfunctionality to support PostgreSQL extensions. This allows users to define and manage extension-specific images within a catalog, simplifying the deployment of customized PostgreSQL builds.

introduced the declarative definition of podSelectorRefs to manage pg_hba.conf rules dynamically. By using label selectors to identify client pods, the operator automatically resolves their ephemeral IP addresses and updates the PostgreSQL host-based authentication rules accordingly. This ensures that only authorized workloads in the same namespace can connect to the database, eliminating the need for manual IP management or static CIDR ranges.

added an optional serviceAccountNamefield to both Cluster and Pooler specifications. This allows multiple resources to share a pre-existing ServiceAccount, facilitating one-time IAM configurations (such as AWS IRSA, GCP Workload Identity, or Azure Workload Identity) across all clusters and poolers. Contributed by @bozkayasalihx.

This enables administrators to meet strict security compliance requirements for pooler-to-client and pooler-to-server connections. Contributed by @alex1989hu.

The operator now automatically deletes the failed job when a user reverts the container image, allowing the cluster to restart gracefully on the original version.

This provides visibility into the operator's decision-making process and the lifecycle of managed resources directly through kubectl get events.

This allows administrators to temporarily freeze the operator's reconciliation logic for specific backup objects. Contributed by @GabriFedi97.

This allows extensions to specify directory paths for external binaries, which are automatically appended to the PATH environment variable of the Postgres process.

This allows cluster administrators to define custom environment variables for the Postgres process. This field supports the ${image_root} placeholder to dynamically resolve to the extension's absolute mount path.

...avoiding unnecessary reconciliation attempts and spurious error messages on read-only replicas.

This ensures the operator stops retrying doomed operations, preventing resource exhaustion and providing immediate, clear feedback in the status.

This change separates the operator's internal lifecycle from the actual backup tool's execution timing (startedAt/stoppedAt), allowing users to track when the operator begins processing a request.

Additionally, enabled Software Bill of Materials (SBOM) generation within the GoReleaser pipeline for improved dependency transparency.

...where pods running the old and new operator versions computed different PostgreSQL configuration hashes, causing the uniformity check to block indefinitely and preventing both rolling updates and in-place upgrades from proceeding.

...because the disk space check blocked the instance manager from starting. The check is now performed later in the lifecycle loop, after fencing is evaluated.

The operator now validates snapshot existence before use; if a snapshot is missing, it attempts to use the next available candidate or falls back topg_basebackup.

Previously, these were incorrectly rejected unless a Barman object store or CNPG-i plugin was also configured.

Fencing operates on a cluster-level annotation and should not depend on pod existence; instance name validation is now performed only in the cnp fencing on command.

Previously, the protection introduced in#9650 only covered in-tree restores, allowing plugins to bypass the check and download future timeline history files, causing timeline mismatch errors on replicas.