VMware Tanzu™ SQL with Postgres for Kubernetes

This document contains pertinent release information about VMware Tanzu SQL with Postges for Kubernetes. Obtain the most recent version of the distribution from VMware Tanzu Network.

Release 1.2.0

Release Date: July 15, 2021

Software Component Versions

VMware Postgres Version Component Component Version
1.2.0 PostgreSQL 11.12
psqlODBC 11.0-0000
pgjdbc 42.2.5
pgBackRest 2.28
pg_auto_failover 1.4.2
postGIS 2.5.5
Orafce 3.14
PL/Java Beta 1.5.7

Supported Platforms

This version of Tanzu Postgres is supported on the following platforms:

Additional Kubernetes environments, such as Minikube, can be used for testing or demonstration purposes.

Features

Tanzu Postgres 1.2.0 has the following new features:

Security Enhancements

  • Tanzu Postgres 1.2.0 supports TLS security and user provided TLS certificates. See Creating a TLS Secret Manually.
  • Support for custom TLS issuer. See Configuring TLS for Tanzu Postgres Instances.
  • TLS certificates associated with cert-manager can be accidentally deleted and regenerated automatically.
  • Kubernetes secrets associated with a cert-manager certificate can be deleted and recovered automatically. A new certificate will be generated, and the Postgres server will restart. Applications will need to reconnect.
  • Tanzu Postgres instances are now created by default with service type ClusterIP, to enhance security.
  • New Postgres instances now use a crypto library/algorithm for enhanced password generation.

Usability Enhancements

  • The Tanzu Postgres Operator and instances are now available via the TanzuNet registry. See Installing a Postgres Operator for more information.
  • This release supports VMware Tanzu Kubernetes Grid multicloud on AWS.
  • PL/Java is bundled with the 1.2 release but currently provided as Beta.
  • Tanzu Postgres now supports the Orafce extension. Users can now run Oracle queries like SELECT months_between(date '1995-02-02', date '1995-01-01');. See Installing Postgres Extensions.
  • Release 1.2 now supports all Postgres contrib extensions, apart from plpython3u.
  • Connections to Postgres instances are now writable by default. This allows applications that cannot use connection parameters such as target_session_attrs(for libpq) or targetServertype(for JDBC) to connect to a writable instance.
  • Users can install the Tanzu Postgres Operator in a namespace of their choice.
  • The new release supports enhanced labels. Users can search the Kubernetes resources created by the Tanzu Postgres Helm chart by using a label such as app=postgres-operator. See Installing a Tanzu Postgres Operator.
  • Users can now set logLevel: Debug when creating an instance. Debug logs can be shared with VMware support for troubleshooting. See Configuring a Postgres Instance.
  • The Postgres instance Monitor pod resources can now be manually altered, to support resource constrained environments such as Minikube on a client laptop. For more details see Updating the Monitor Resources.
  • Release 1.2 now supports all Postgres contrib extensions, apart from plpython3u. For more information see Additional Supplied Modules in the Postgres documentation.

Fixed Issues

  • (175768688) - Users can now create backups of similarly named instances in the same S3 bucket.
  • (176064027) - When creating a backup operation, users do not need to specify the path --pg1-path on the command line.
  • (175771699) - This release improves the error message when specifying below the minimum accepted disk space for the StorageSize field:
    "pg-small-instance.yaml": admission webhook "vpostgres.kb.io" denied the request: The field(s) StorageSize field needs to be at least 250MB are incorrectly formatted and could not be parsed.
  • (177225289) - Users can now specify the StorageSize field using M, Mi, or MB.
  • (176615909) - Non-admin users can now view Postgres objects in a specified namespace.
  • (178402085) - Fixes a log display issue where, if the instance was older than one day, the logs stopped displaying to stdout.
  • (177407650) - Fixes an issue where the database would be inaccessible for a period of time when scaling up from a single node to an HA configuration. The database is now accessible during the secondary node data copy period.
  • (178528901) - In a HA configuration, when the user configured a S3 backup secret, he also had to manually create the backup stanza. This issue has been resolved, and the backup stanza is created automatically when users apply the S3 secret.

Limitations

  • The High Availability configuration contains only one mirror.

  • The dockerRegistrySecretName in the Operator values.yaml file is set to regsecret and cannot be changed to an alternative name in the overrides file .