gitlab ongresinc/stackgres 1.19.2

3 hours ago

🚀 Release 1.19.2 (2026-09-29)

🗒 NOTES

StackGres 1.19.2 is out! 🐛 🔫 🎣 🎊 🍻

This release brings an important security improvement over the restart operation implemented in
StackGres 1.18 where the primary where restarted without a switchover during rollout (like a
restart SGDbOps) whenever a parameter that requires restart was changed.
Also a new field restartDelay has been added to rollout (affect also restart, security upgrade
and minor version upgrade) in order to overcome the limitation of controllers like patroni and
the StatefulSet Kubernetes controller that may have some delay in updating the status thus making
the restart operation complete before the cluster is completely restarted.
A bug of the new query routers feature introduced in version 1.19 was leaving some nodes with
shouldhaveshards set to true in pg_dist_node.

So, what you are waiting for to try this release and have a look to the future of StackGres!

✨ NEW FEATURES AND CHANGES

  • PgBouncer 1.26.0
  • Fluent-bit 5.1.2
  • Fluentd 1.19.3
  • Kubectl 1.36.5 and 1.37.1
  • OTEL Contrib Collector 0.161.0
  • The primary is restarted without a switchover only when a hot standby sensitive parameter is decreased
    (#3233)
  • New SGCluster.spec.pods.updateStrategy.restartDelay (and the SGShardedCluster equivalent) to set the delay between the restart of a Postgres instance
    performed by the cluster controller and the next one (#3233)
  • New statusUpdateDelay on the restart, securityUpgrade and minorVersionUpgrade sections of SGDbOps, the delay that has to pass since the last
    status update before the operation can be considered completed. Defaults to PT5S (#3236)
  • New SGCluster.spec.configurations.patroni.startGateAnnotations to start Patroni only once the SGCluster has all the specified annotations (#3245)
  • New SGScript.spec.scripts[].setValue to store the value returned by the query of a script entry in SGCluster.status.managedSql.scripts[].scripts[].value and SGScript.spec.scripts[].cron to execute a script entry following a Quartz cron schedule (#3245)
  • New SGShardedCluster.spec.configurations.citus.updateNodeInterval (defaults to PT10S) and SGShardedCluster.spec.configurations.citus.enableNodeAutoRemoval (disabled by default) to configure how the coordinator maintains pg_dist_node (#3244, #3245)
  • The persistent volume size of SGCluster and SGShardedCluster is no longer validated by the operator: whether a volume can be expanded or shrunk is left to Kubernetes and the StorageClass implementation (#3246)
  • New SGShardedCluster.spec.configurations.citus.connectToPooler (enabled by default) to make the citus nodes connect to each other through PgBouncer instead of connecting directly to Postgres. When enabled PgBouncer is always created, ignoring the disableConnectionPooling fields (#3247)

Web Console

Nothing new here! 👀

🐛 FIXES

  • A change of only the labels or annotations of an SGCluster, SGShardedCluster or any other StackGres custom resource generated by the operator (like the SGClusters of an SGShardedCluster) was never applied, since the equals of the StackGres custom resources did not take into account the metadata
  • A SGShardedCluster emitted a ClusterUpdated event and re-created, deleted and patched the same resources on every reconciliation cycle, without ever converging (#3219)
  • The PendingUpgrade condition of a SGShardedCluster ignored its SGClusters and stayed True after an operator upgrade within the same minor version.
    It is now aggregated from the children and states what is pending and what clears it. PendingRestart was also ignoring a child whose restart was pending for a reason other than PodRequiresRestart (#3220)
  • A completed SGShardedDbOps made the reconciliation loop fail on every cycle with a misleading message about a non existent SGShardedCluster (#3221)
  • A conflict while patching the Pods or the PersistentVolumeClaims of a cluster being restarted aborted the whole reconciliation cycle instead of being retried (#3222)
  • The SGPostgresConfig and SGPoolingConfig referenced by an SGShardedCluster query router override (spec.workers.overrides[] with type: QueryRouter) were ignored and the ones of the workers were used instead. A query router without an override now uses the configurations of spec.coordinator, as documented, instead of the ones of spec.workers (#3226)
  • The query routers of a citus SGShardedCluster were registered in pg_dist_node with shouldhaveshards = true for up to 30 seconds, so a create_distributed_table executed in that window placed shards on them. They are now registered without shards before their Patroni is started (#3245)
  • The nodes of the workers and query routers removed by decreasing workers.clusters or queryRouterClusters were never removed from pg_dist_node and made Citus reject any node addition and distributed DDL. The SGCluster of a removed worker or query router is now kept running while its group is registered in pg_dist_node (Citus can only remove a primary node that can be reached) and scaled down once its group is gone, and the nodes can be removed automatically with SGShardedCluster.spec.configurations.citus.enableNodeAutoRemoval (#3244)
  • Deleting an SGCluster completed while its Pods were still terminating, so a cluster recreated with the same name could deadlock at waiting for leader to bootstrap. The new stackgres.io/wait-pods-termination finalizer makes the deletion complete only once the Pods of the cluster are gone. It does not wait when the SGCluster is deleted with --cascade=orphan, and it stops waiting for Pods still terminating 2 minutes after their termination grace period (#3240)
  • SGShardedCluster reconciliation reverts status changes made during a cycle, leaving status.dbOps set forever (#3241)
  • A major version upgrade of a citus SGShardedCluster lost the whole citus metadata. The upgraded cluster came up on the target Postgres version but was not a citus cluster anymore, with no nodes, no distributed tables and no shards, and could not be repaired either since citus did not know the coordinator was the coordinator (#3242)
  • The Job that labels the allowed namespaces could not start, so installing or upgrading the operator with allowedNamespaces set never completed. Its Pod security context set runAsNonRoot without setting runAsUser, and the image it runs has a non numeric user, so the kubelet refused the container
    (#3243)
  • The extensions cache was never asked for anything. The SGCONFIG environment variable of the operator Deployment was rendered without the proxyUrl parameter that points the repository URLs at the cache, and the operator merged it over the SGConfig installed by the pre-install hook, which had it
  • A read-modify-write of a custom resource rewrote it without the fields the running build does not model, so after an operator upgrade the cluster controller and the REST API dropped the fields added by the new version (#3232)
  • Outdated and broken information in README.md and stackgres-k8s/src/README.md (#3234)

Web Console

Nothing new here! 👀

🚧 KNOWN ISSUES

  • Backups may be restored with inconsistencies when performed with a Postgres instance running on a different architecture
    (#1539)

🆙 UPGRADE

To upgrade from a previous installation of the StackGres operator's helm chart you will have to upgrade the helm chart release.
For more detailed information please refer to our documentation.

To upgrade StackGres operator's (upgrade only works starting from 1.1 version or above) helm chart issue the following commands (replace namespace and release
name if you used something different):

helm upgrade -n "stackgres" "stackgres-operator" https://stackgres.io/downloads/stackgres-k8s/stackgres/1.19.2/helm/stackgres-operator.tgz

IMPORTANT: SGClusters now have the stackgres.io/wait-pods-termination finalizer, that is removed by the operator. Delete
the SGClusters and SGShardedClusters before uninstalling the operator, or remove the finalizer manually as described in
the uninstall guide.

IMPORTANT: This release is incompatible with previous alpha or beta versions. Upgrading from those versions will require uninstalling completely
StackGres including all clusters and StackGres CRDs (those in stackgres.io group) first.

Thank you for all the issues created, ideas, and code contributions by the StackGres Community!

🔀 FULL LIST OF COMMITS

Don't miss a new stackgres release

NewReleases is sending notifications on new releases.