zalando
Support for postgres 15 beta
I was wondering if it is possible to use postgres 15 beta with the operator. I just wanted to try new features built in postgres 15. If so, how? Thanks!
Yes, thanks to @hughcapet! now there is a feature branch with Postgres 15, but you'll have to build the image on your own.
I successfully built postgres 15 spilo image, but the operator says that the 15 version is not valid and installs 14.4, what should I do? Thanks!
I had to add the version 15 to the enum in the CRD:
kubectl edit crd postgresqls.acid.zalan.do
Indeed, you have to add 15 to the CRD manually. The operator will overwrite it on next restart, I think. But should work temporarily. Will add 15 soon and remove 9.5 and 9.6.
Any ideas on how can I patch this automatically until this gets done? Maybe I should be able to make a kubectl patch on the CRD? I don't quite control this command. Now I'm having trouble when the CRD is modified as I have to manually change that, and would be nice to automate this in the build pipeline.
I came across with just a cheap and dirty patch but it works meanwhile, drop suport for postgresql replacing by 15:
kubectl get crd postgresqls.acid.zalan.do -n "${POSTGRES_OPERATOR_NAMESPACE}" -o yaml > operator.yaml
sed -i 's/"13"/"15"/g' operator.yaml
kubectl apply -f operator.yaml -n "${POSTGRES_OPERATOR_NAMESPACE}"
Spilo image has already merged postgresql15 support to the main branch:
https://github.com/zalando/spilo/pull/794
It would be nice adding support for this, as this requires minimal changes.
spilo-15:2.1-p9 postgres-operator: 1.8.1 PG version "15" was added manually to CRD. After that:
-
It was possible to scratch install DB cluster and PG 15 became in use (PG 15.1). Well, with message: msg="cluster version up to date. current: 140006, min desired: 0", but still got installed.
-
But, a separate major version test case failed: postgres-operator does not seem to try to trigger major version upgrade from 14 to 15?
I'm using the Postgres Operator 1.9.0 with PG 15 (psql (15.1 (Ubuntu 15.1-1.pgdg22.04+1)) and it seems to be working as expected other than for Spilo backups to S3. Here's the exception I see when the Spilo pod starts up:
IPv4
API Endpoint: https://10.100.0.1:443/api/v1
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 18614 0 18614 0 0 1136k 0 --:--:-- --:--:-- --:--:-- 1136k
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 115 100 115 0 0 8846 0 --:--:-- --:--:-- --:--:-- 8846
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 115 100 115 0 0 8214 0 --:--:-- --:--:-- --:--:-- 8214
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 20590 0 20590 0 0 1546k 0 --:--:-- --:--:-- --:--:-- 1546k
+ compress
+ dump
+ pigz
+ /usr/lib/postgresql/15/bin/pg_dumpall
/dump.sh: line 36: /usr/lib/postgresql/15/bin/pg_dumpall: No such file or directory
+ upload
+ case $LOGICAL_BACKUP_PROVIDER in
++ estimate_size
++ /usr/lib/postgresql/15/bin/psql -tqAc 'select sum(pg_database_size(datname)::numeric) from pg_database;'
/dump.sh: line 31: /usr/lib/postgresql/15/bin/psql: No such file or directory
/dump.sh: line 124: / DUMP_SIZE_COEFF: syntax error: operand expected (error token is "/ DUMP_SIZE_COEFF")
Stream closed EOF for cores/core-db-core-db-1-27932970-6rqbk (logical-backup)
It seems that it's not using PG 15 even though the underlying container image is ghcr.io/zalando/spilo-15:2.1-p9.
Any insight is appreciated.
So, I ended up needing to ensure the CRDs were updated as per these instructions.
However, once that was complete and the operator updated, it seems the cronjob for the backup still references the v1.8.0 logical backup image in the container stanza.
image: registry.opensource.zalan.do/acid/logical-backup:v1.8.0
imagePullPolicy: IfNotPresent
name: logical-backup
I manually edited the cronjob to use v1.9.0 but it keeps reverting back (assuming by the operator) even though I have confirmed the operatorconfigurations.acid.zalan.do CRD contains the correct logical backup reference in the logical_backup stanza:
logical_backup_docker_image:
Default: registry.opensource.zalan.do/acid/logical-backup:v1.9.0
Type: string
UPDATE: I diagnosed the issue in that, for Postgres 15, I needed to specify logical_backup_docker_image: "registry.opensource.zalan.do/acid/logical-backup:v1.9.0" in the configLogicalBackup stanza of the values file.
UPDATE: I diagnosed the issue in that, for Postgres 15, I needed to specify
logical_backup_docker_image: "registry.opensource.zalan.do/acid/logical-backup:v1.9.0"in theconfigLogicalBackupstanza of the values file.
It seems that default value is already present on the chart since https://github.com/zalando/postgres-operator/commit/30b612489a2a20d968262791857d1db1a85e0b36. However, your operator confguration will keep the old default if it was deployed before 1.9.0 and you didn't specify the image. Weird...
Sorry I was wrong. That commit didn't update the default: https://github.com/zalando/postgres-operator/blob/9973262b83507ccb16c097aef9ca56b35a1cbf4a/charts/postgres-operator/values.yaml#L351