Released: 16 September 2026
Highlights
- The connection manager (proxy) services now route only to data nodes that have joined the PGD group and are active members, so a node that is still joining or has no routing no longer receives client traffic. Once a node is a member, its pod readiness probe reports the connection manager's
/connection/is-readyendpoint instead of Postgres readiness. - The operator no longer restarts a PGD node when the raft cannot spare a member. Both the parent raft and, for locally routed groups, the local subgroup raft must still reach quorum after losing one more member. Nodes that do not answer the raft or have not joined yet are not counted, and a held node does not block others in the same pass.
- With the fix of CVE-2026-55769 in CloudNativePG
1.28.4or later,search_pathis now pinned topg_catalog, public, pg_tempon every operator-issued connection. The PGD operator's mutation reconciler now scopessearch_pathtopublicfor the duration of eachPGDGroupmutation transaction, so unqualifiedCREATEstatements in user-authored mutations continue to land in the intended schema instead of failing with a permission error.
Upgrade notes
- PGD Essential is no longer supported. Image catalogs are generated for the expanded edition only, so no new
*-essential-ubi9catalog is published and essential operand images are no longer tested. The operator does not reject an essential operand image, but a group running one is no longer on a supported configuration and should be moved to the matching expanded image. - Data node pods are recreated once, node by node, during the upgrade: repointing the readiness probe at the connection manager changes the pod definition. The write leader is updated last, as for any other node configuration change. On a new group the repoint happens before the group is created and before any node joins it, and the group waits for every pending recreation to complete before joining a node, so no node is recreated while it is joining. A node added through a physical join is repointed while it is still hibernated and is not recreated at all.
- A data node pod reports
NotReadywhile its connection manager has no route to serve — for example when the group loses raft consensus, or when the node is fenced withroute_fence. Consequences: - Node services are now created with
publishNotReadyAddresses=trueso the operator can reach a node whose connection manager is not ready. Existing node services are healed in place, keeping any externally assignedLoadBalancerIP.publishNotReadyAddressesis operator-managed onnodeServiceTemplate: any value supplied in the template is overridden withtrue. - Pausing a
PGDGroupwaits for every data node to be ready, and readiness now observes the connection manager: the operator compares each CloudNativePG cluster'sReadyInstancesagainst itsSpec.Instances, so a fenced or route-less data node delays the pause of the group until it can serve again. - A node is promoted to routable only once, and only a part demotes it automatically: a transient loss of the PGD status, or a routing switch between the local and the parent group, does not rewrite the pod definition. Disabling
enable_routingon a group whose nodes are already routable therefore leaves their pods reportingNotReady, because the connection manager has no route to serve; see thedisableConnMgrReadinessProbeannotation to demote them back to the Postgres readiness probe. - The
nodeRoutablepromotion label is applied to a data node pod together with the connection manager readiness probe, when the pod is created. A promoted node therefore never appears in the connection manager services one restart before it can serve them, so upgrading the operator does not empty their endpoints. A parted node is demoted on the running pod, without a restart.
Supported versions
- Kubernetes: 1.34, 1.35, and 1.36
- PostgreSQL: 18, 17, 16, 15, and 14
- The tested PG4K version is v1.28.4
- Update the default PGD image to PostgreSQL 18.6 and PGD 6.5.0 expanded (image
postgresql-pgd:18.6-pgd650-expanded-ubi9)
This release of EDB Postgres® AI for CloudNativePG™ Global Cluster includes the following:
Features
| Description |
|---|
The operator log level can now be set from the operator's ConfigMap or Secret with the OPERATOR_LOG_LEVEL key, which overrides the log level configured in the operator deployment. Accepted values are trace, debug, info, warn, and error. |
The labels and annotations of a PGDGroup are now inherited by the physical join job it creates, so the job is selected by the same label-based tooling — network policies, cost allocation, monitoring — as the rest of the group. |
The group phase Waiting for Connection Manager to be ready now names the nodes whose connection manager is not live or not ready. |
Security Fixes
| Description |
|---|
| Bump the go version to v1.27.1 |
| Bump grpc go module version to v1.83.2 |
Bug Fixes
| Description |
|---|
| The raft consensus verdict of a group is now decided from the fullest view of the raft the operator can read, instead of whatever the first node to answer reported. Raft health is group-wide, so one reachable node is enough: a lagging, minority, just-restarted or unreachable node no longer keeps a recovered group stuck in a critical phase or blocks a node from joining. |
| A PGD group in a failed phase is now re-evaluated every 10 seconds rather than every 60, so a group that has already recovered stops reporting the failure sooner. |
| A change that rewrites the pod definition of a data node is now applied to one node at a time. CloudNativePG accepts a cluster change before it deletes the pod, and the operator read that short interval as "done" and moved on to the next node, taking two nodes down at once. The group reconciliation now waits until the rollout of the previous node is visible, so a rolling change takes longer but never overlaps. |
| A node added through a physical join now waits for a source node that is an active PGD member. On a freshly restored group the only candidate could still be in point-in-time recovery, and its promotion restart aborted the base backup mid-copy; every retry then failed on a tablespace directory that was no longer empty, leaving the joining node permanently stuck. |
The physical join job now retries transient failures on its own, with a BackoffLimit of 3, and is reported as Failed only once those retries are exhausted. See Physical join for what to do with a job that has failed. |
The pods the operator manages for a group are now selected by their instance role. A completed initdb or physical-join job pod carries the same group and cluster labels and keeps its pod IP until it is cleaned up, so it could be picked instead of the instance pod, and the connection manager probe of that node pinned the group at Waiting for Connection Manager to be ready. |
The output of bdr_init_physical is now streamed to the container log as it is produced, instead of being written to a file on the pod's ephemeral volume that was lost with the pod. Physical join failures can be diagnosed from the pod logs, including when the pod is killed. |
| A node is bootstrapped into a new group, or joined to an existing one, only once the raft of the parent group has a leader, has consensus, and has no other node mid-join. The join job verifies this on the join target itself, and the cross-location group bootstrap is guarded the same way, so the request reaches a node that can commit it. |
The manager group subcommands — barman restore, join, remote join and group bootstrap — now write their logs and honor --log-level and --log-destination. |
| Deleting a region no longer stalls a physical join group. A node deleted while the operator was reconciling the group's nodes failed the whole reconcile, which then retried on the same missing node, and the group stopped making progress on its removal. Such a node is now skipped. |