Navigation :

4.3.4

Crunchy Data announces the release of the PostgreSQL Operator 4.3.4 on November 20, 2020.

The PostgreSQL Operator is released in conjunction with the Crunchy Container Suite.

The PostgreSQL Operator 4.3.4 release includes the following software versions upgrades:

  • The PostgreSQL containers now use versions 12.5, 11.10, 10.15, 9.6.20, and 9.5.24

PostgreSQL Operator is tested with Kubernetes 1.13 - 1.18, OpenShift 3.11+, OpenShift 4.3+, Google Kubernetes Engine (GKE), and VMware Enterprise PKS 1.3+.

Fixes

  • Proper determination if a pgcluster custom resource creation has been processed by its corresponding Postgres Operator controller. This prevents the custom resource from being run by the creation logic multiple times.
  • The pgo scaledown now allows for the removal of replicas that are not actively running.
  • The pgo scaledown --query command now shows replicas that may not be in an active state.
  • Ensure pgBouncer Port is derived from the cluster’s port, not the Operator configuration defaults.
  • Fix readiness check for a standby leader. Previously, the standby leader would not report as ready, even though it was. Reported by Alec Rooney (@alrooney).
  • External WAL PVCs are only removed for the replica they are targeted for on a scaledown. Reported by (@dakine1111).
  • Ensure pgo show backup will work regardless of state of any of the PostgreSQL clusters. This pulls the information directly from the pgBackRest Pod itself. Reported by (@saltenhub).
  • When deleting a cluster with the --keep-backups flag, ensure that backups that were created via --backup-type=pgdump are retained.
  • Return an error if a cluster is not found when using pgo df instead of timing out.
  • The operator container will no longer panic if all Deployments are scaled to 0 without using the pgo update cluster <mycluster> --shutdown command.
  • Allow for special characters in pgBackRest environmental variables. Reported by (@SockenSalat).
  • Ensure password for the pgbouncer administrative user stays synchronized between an existing Kubernetes Secret and PostgreSQL should the pgBouncer be recreated.
  • The logger no longer defaults to using a log level of DEBUG.