Head2

.github/workflows/publish_ghcr_image.yaml

@@ -23,7 +23,7 @@ jobs:
 
       - uses: actions/setup-go@v2
         with:
-          go-version: "^1.23.4"
+          go-version: "^1.25.0"
 
       - name: Run unit tests
         run: make deps mocks test

.github/workflows/run_e2e.yaml

@@ -14,7 +14,7 @@ jobs:
     - uses: actions/checkout@v1
     - uses: actions/setup-go@v2
       with:
-          go-version: "^1.23.4"
+          go-version: "^1.25.0"
     - name: Make dependencies
       run: make deps mocks
     - name: Code generation

.github/workflows/run_tests.yaml

@@ -14,7 +14,7 @@ jobs:
     - uses: actions/checkout@v2
     - uses: actions/setup-go@v2
       with:
-          go-version: "^1.23.4"
+          go-version: "^1.25.0"
     - name: Make dependencies
       run: make deps mocks
     - name: Compile

Makefile

@@ -43,7 +43,7 @@ ifndef GOPATH
 endif
 
 PATH := $(GOPATH)/bin:$(PATH)
-SHELL := env PATH=$(PATH) $(SHELL)
+SHELL := env PATH="$(PATH)" $(SHELL)
 
 default: local
 
@@ -69,7 +69,7 @@ docker: ${DOCKERDIR}/${DOCKERFILE}
 	docker build --rm -t "$(IMAGE):$(TAG)$(CDP_TAG)$(DEBUG_FRESH)$(DEBUG_POSTFIX)" -f "${DOCKERDIR}/${DOCKERFILE}" --build-arg VERSION="${VERSION}" .
 
 indocker-race:
-	docker run --rm -v "${GOPATH}":"${GOPATH}" -e GOPATH="${GOPATH}" -e RACE=1 -w ${PWD} golang:1.23.4 bash -c "make linux"
+	docker run --rm -v "${GOPATH}":"${GOPATH}" -e GOPATH="${GOPATH}" -e RACE=1 -w ${PWD} golang:1.25.0 bash -c "make linux"
 
 push:
 	docker push "$(IMAGE):$(TAG)$(CDP_TAG)"

charts/postgres-operator-ui/values.yaml

@@ -62,8 +62,6 @@ podAnnotations:
 extraEnvs:
   []
   # Exemple of settings to make snapshot view working in the ui when using AWS
-  # - name: WALE_S3_ENDPOINT
-  #   value: https+path://s3.us-east-1.amazonaws.com:443
   # - name: SPILO_S3_BACKUP_PREFIX
   #   value: spilo/
   # - name: AWS_ACCESS_KEY_ID
@@ -83,8 +81,6 @@ extraEnvs:
   #       key: AWS_DEFAULT_REGION
   # - name: SPILO_S3_BACKUP_BUCKET
   #   value: <s3 bucket used by the operator>
-  # - name: "USE_AWS_INSTANCE_PROFILE"
-  #   value: "true"
 
 # configure UI service
 service:

charts/postgres-operator/values.yaml

@@ -364,7 +364,7 @@ configLogicalBackup:
   # logical_backup_memory_request: ""
 
   # image for pods of the logical backup job (example runs pg_dumpall)
-  logical_backup_docker_image: "ghcr.io/zalando/postgres-operator/logical-backup:v1.13.0"
+  logical_backup_docker_image: "ghcr.io/zalando/postgres-operator/logical-backup:v1.14.0"
   # path of google cloud service account json file
   # logical_backup_google_application_credentials: ""
 

docker/DebugDockerfile

@@ -1,4 +1,4 @@
-FROM golang:1.23-alpine
+FROM golang:1.25-alpine
 LABEL maintainer="Team ACID @ Zalando <team-acid@zalando.de>"
 
 # We need root certificates to deal with teams api over https

docker/Dockerfile

@@ -1,5 +1,5 @@
 ARG BASE_IMAGE=registry.opensource.zalan.do/library/alpine-3:latest
-FROM golang:1.23-alpine AS builder
+FROM golang:1.25-alpine AS builder
 ARG VERSION=latest
 
 COPY  . /go/src/github.com/zalando/postgres-operator

docker/build_operator.sh

@@ -13,7 +13,7 @@ apt-get install -y wget
 
 (
     cd /tmp
-    wget -q "https://storage.googleapis.com/golang/go1.23.4.linux-${arch}.tar.gz" -O go.tar.gz
+    wget -q "https://storage.googleapis.com/golang/go1.25.0.linux-${arch}.tar.gz" -O go.tar.gz
     tar -xf go.tar.gz
     mv go /usr/local
     ln -s /usr/local/go/bin/go /usr/bin/go

docs/administrator.md

@@ -384,7 +384,7 @@ exceptions:
 The interval of days can be set with `password_rotation_interval` (default
 `90` = 90 days, minimum 1). On each rotation the user name and password values
 are replaced in the K8s secret. They belong to a newly created user named after
-the original role plus rotation date in YYMMDD format. All priviliges are
+the original role plus rotation date in YYMMDD format. All privileges are
 inherited meaning that migration scripts should still grant and revoke rights
 against the original role. The timestamp of the next rotation (in RFC 3339
 format, UTC timezone) is written to the secret as well. Note, if the rotation
@@ -564,7 +564,7 @@ manifest affinity.
 ```
 
 If `node_readiness_label_merge` is set to `"OR"` (default) the readiness label
-affinty will be appended with its own expressions block:
+affinity will be appended with its own expressions block:
 
 ```yaml
   affinity:
@@ -620,22 +620,34 @@ By default the topology key for the pod anti affinity is set to
 `kubernetes.io/hostname`, you can set another topology key e.g.
 `failure-domain.beta.kubernetes.io/zone`. See [built-in node labels](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#interlude-built-in-node-labels) for available topology keys.
 
-## Pod Disruption Budget
+## Pod Disruption Budgets
 
-By default the operator uses a PodDisruptionBudget (PDB) to protect the cluster
-from voluntarily disruptions and hence unwanted DB downtime. The `MinAvailable`
-parameter of the PDB is set to `1` which prevents killing masters in single-node
-clusters and/or the last remaining running instance in a multi-node cluster.
+By default the operator creates two PodDisruptionBudgets (PDB) to protect the cluster
+from voluntarily disruptions and hence unwanted DB downtime: so-called primary PDB and
+and PDB for critical operations.
+
+### Primary PDB
+The `MinAvailable` parameter of this PDB is set to `1` and, if `pdb_master_label_selector`
+is enabled, label selector includes `spilo-role=master` condition, which prevents killing
+masters in single-node clusters and/or the last remaining running instance in a multi-node
+cluster.
+
+## PDB for critical operations
+The `MinAvailable` parameter of this PDB is equal to the `numberOfInstances` set in the
+cluster manifest, while label selector includes `critical-operation=true` condition. This
+allows to protect all pods of a cluster, given they are labeled accordingly.
+For example, Operator labels all Spilo pods with `critical-operation=true` during the major
+version upgrade run. You may want to protect cluster pods during other critical operations
+by assigning the label to pods yourself or using other means of automation.
 
 The PDB is only relaxed in two scenarios:
 
 * If a cluster is scaled down to `0` instances (e.g. for draining nodes)
 * If the PDB is disabled in the configuration (`enable_pod_disruption_budget`)
 
-The PDB is still in place having `MinAvailable` set to `0`. If enabled it will
-be automatically set to `1` on scale up. Disabling PDBs helps avoiding blocking
-Kubernetes upgrades in managed K8s environments at the cost of prolonged DB
-downtime. See PR [#384](https://github.com/zalando/postgres-operator/pull/384)
+The PDBs are still in place having `MinAvailable` set to `0`. Disabling PDBs
+helps avoiding blocking Kubernetes upgrades in managed K8s environments at the
+cost of prolonged DB downtime. See PR [#384](https://github.com/zalando/postgres-operator/pull/384)
 for the use case.
 
 ## Add cluster-specific labels
@@ -1128,7 +1140,7 @@ metadata:
     iam.gke.io/gcp-service-account: <GCP_SERVICE_ACCOUNT_NAME>@<GCP_PROJECT_ID>.iam.gserviceaccount.com
 ```
 
-2. Specify the new custom service account in your [operator paramaters](./reference/operator_parameters.md)
+2. Specify the new custom service account in your [operator parameters](./reference/operator_parameters.md)
 
 If using manual deployment or kustomize, this is done by setting
 `pod_service_account_name` in your configuration file specified in the

docs/quickstart.md

@@ -230,7 +230,7 @@ kubectl delete postgresql acid-minimal-cluster
 ```
 
 This should remove the associated StatefulSet, database Pods, Services and
-Endpoints. The PersistentVolumes are released and the PodDisruptionBudget is
+Endpoints. The PersistentVolumes are released and the PodDisruptionBudgets are
 deleted. Secrets however are not deleted and backups will remain in place.
 
 When deleting a cluster while it is still starting up or got stuck during that

docs/reference/cluster_manifest.md

@@ -116,9 +116,9 @@ These parameters are grouped directly under  the `spec` key in the manifest.
 
 * **maintenanceWindows**
   a list which defines specific time frames when certain maintenance operations
-  are allowed. So far, it is only implemented for automatic major version
-  upgrades. Accepted formats are "01:00-06:00" for daily maintenance windows or 
-  "Sat:00:00-04:00" for specific days, with all times in UTC.
+  such as automatic major upgrades or master pod migration. Accepted formats
+  are "01:00-06:00" for daily maintenance windows or "Sat:00:00-04:00" for specific
+  days, with all times in UTC.
 
 * **users**
   a map of usernames to user flags for the users that should be created in the
@@ -247,7 +247,7 @@ These parameters are grouped directly under  the `spec` key in the manifest.
   [kubernetes volumeSource](https://godoc.org/k8s.io/api/core/v1#VolumeSource).
   It allows you to mount existing PersistentVolumeClaims, ConfigMaps and Secrets inside the StatefulSet.
   Also an `emptyDir` volume can be shared between initContainer and statefulSet.
-  Additionaly, you can provide a `SubPath` for volume mount (a file in a configMap source volume, for example).
+  Additionally, you can provide a `SubPath` for volume mount (a file in a configMap source volume, for example).
   Set `isSubPathExpr` to true if you want to include [API environment variables](https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath-expanded-environment).
   You can also specify in which container the additional Volumes will be mounted with the `targetContainers` array option.
   If `targetContainers` is empty, additional volumes will be mounted only in the `postgres` container.
@@ -257,7 +257,7 @@ These parameters are grouped directly under  the `spec` key in the manifest.
 ## Prepared Databases
 
 The operator can create databases with default owner, reader and writer roles
-without the need to specifiy them under `users` or `databases` sections. Those
+without the need to specify them under `users` or `databases` sections. Those
 parameters are grouped under the `preparedDatabases` top-level key. For more
 information, see [user docs](../user.md#prepared-databases-with-roles-and-default-privileges).
 

docs/reference/operator_parameters.md

@@ -209,7 +209,7 @@ under the `users` key.
   For all `LOGIN` roles that are not database owners the operator can rotate
   credentials in the corresponding K8s secrets by replacing the username and
   password. This means, new users will be added on each rotation inheriting
-  all priviliges from the original roles. The rotation date (in YYMMDD format)
+  all privileges from the original roles. The rotation date (in YYMMDD format)
   is appended to the names of the new user. The timestamp of the next rotation
   is written to the secret. The default is `false`.
 
@@ -334,13 +334,13 @@ configuration they are grouped under the `kubernetes` key.
   pod namespace).
 
 * **pdb_name_format**
-  defines the template for PDB (Pod Disruption Budget) names created by the
+  defines the template for primary PDB (Pod Disruption Budget) name created by the
   operator. The default is `postgres-{cluster}-pdb`, where `{cluster}` is
   replaced by the cluster name. Only the `{cluster}` placeholders is allowed in
   the template.
 
 * **pdb_master_label_selector**
-  By default the PDB will match the master role hence preventing nodes to be
+  By default the primary PDB will match the master role hence preventing nodes to be
   drained if the node_readiness_label is not used. If this option if set to
   `false` the `spilo-role=master` selector will not be added to the PDB.
 
@@ -552,7 +552,7 @@ configuration they are grouped under the `kubernetes` key.
   pods with `InitialDelaySeconds: 6`, `PeriodSeconds: 10`, `TimeoutSeconds: 5`,
   `SuccessThreshold: 1` and `FailureThreshold: 3`. When enabling readiness
   probes it is recommended to switch the `pod_management_policy` to `parallel`
-  to avoid unneccesary waiting times in case of multiple instances failing.
+  to avoid unnecessary waiting times in case of multiple instances failing.
   The default is `false`.
 
 * **storage_resize_mode**
@@ -701,7 +701,7 @@ In the CRD-based configuration they are grouped under the `load_balancer` key.
   replaced by the cluster name, `{namespace}` is replaced with the namespace
   and `{hostedzone}` is replaced with the hosted zone (the value of the
   `db_hosted_zone` parameter). The `{team}` placeholder can still be used,
-  although it is not recommened because the team of a cluster can change.
+  although it is not recommended because the team of a cluster can change.
   If the cluster name starts with the `teamId` it will also be part of the
   DNS, aynway. No other placeholders are allowed!
 
@@ -720,7 +720,7 @@ In the CRD-based configuration they are grouped under the `load_balancer` key.
   is replaced by the cluster name, `{namespace}` is replaced with the
   namespace and `{hostedzone}` is replaced with the hosted zone (the value of
   the `db_hosted_zone` parameter). The `{team}` placeholder can still be used,
-  although it is not recommened because the team of a cluster can change.
+  although it is not recommended because the team of a cluster can change.
   If the cluster name starts with the `teamId` it will also be part of the
   DNS, aynway. No other placeholders are allowed!
 

docs/user.md

@@ -900,7 +900,7 @@ the PostgreSQL version between source and target cluster has to be the same.
 
 To start a cluster as standby, add the following `standby` section in the YAML
 file. You can stream changes from archived WAL files (AWS S3 or Google Cloud
-Storage) or from a remote primary. Only one option can be specfied in the
+Storage) or from a remote primary. Only one option can be specified in the
 manifest:
 
 ```yaml
@@ -911,7 +911,7 @@ spec:
 
 For GCS, you have to define STANDBY_GOOGLE_APPLICATION_CREDENTIALS as a
 [custom pod environment variable](administrator.md#custom-pod-environment-variables).
-It is not set from the config to allow for overridding.
+It is not set from the config to allow for overriding.
 
 ```yaml
 spec:
@@ -1282,7 +1282,7 @@ minutes if the certificates have changed and reloads postgres accordingly.
 ### TLS certificates for connection pooler
 
 By default, the pgBouncer image generates its own TLS certificate like Spilo.
-When the `tls` section is specfied in the manifest it will be used for the
+When the `tls` section is specified in the manifest it will be used for the
 connection pooler pod(s) as well. The security context options are hard coded
 to `runAsUser: 100` and `runAsGroup: 101`. The `fsGroup` will be the same
 like for Spilo.