Trusted Postgres Architect 23.44.1 release notes v23.44.0

YAML parses unquoted off, on, yes and no as booleans, so a setting such as bdr.default_streaming_mode: off inpostgres_conf_settings reached TPA as a boolean and was written topostgresql.conf as False. Postgres accepts that for genuine boolean parameters, but rejects it for enum parameters whose valid values include off or on (for example bdr.default_streaming_mode), so the value was silently ignored and the parameter was left at its default.

TPA now writes boolean values in postgres_conf_settings as on oroff, which Postgres accepts both as boolean values and as enum labels. Quoting values exactly as they should appear inpostgresql.conf remains the recommended practice.

On clusters that used unquoted boolean values inpostgres_conf_settings, Postgres will be restarted on the next run of tpaexec deploy.

A BDR 4 to PGD 5 upgrade that was interrupted after the data nodes reached PGD 5 but before harp-proxy was replaced with pgd-proxy used to be misdetected as a minor PGD 5 upgrade on the next run, and would abort trying to stop a pgd-proxy service that had never been installed. tpaexec upgrade now recognises this half-migrated state and resumes the harp-proxy to pgd-proxy migration, so a failed upgrade can be recovered simply by re-running the command.

To make this process reliable, reconfiguring a BDR 3/4 cluster to PGD 5 now defaults upgrade_components to postgres, pgd-proxy, pgdcli (unless you have already set it), so the upgrade migrates the data nodes, replaces harp-proxy with pgd-proxy, and moves pgd-cli onto the PGD 5 line in the same run. You must upgrade these three components together, and a major BDR 3/4 to PGD 5 upgrade that would upgrade some but not all of them now stops before making any changes.

Upgrading pgd-proxy now also re-renders its configuration file and systemd unit between installing the new package and restarting the service, so a newer pgd-proxy that changes its configuration layout or service unit starts cleanly against freshly rendered files.

On RHEL 9 minor versions 9.7 and later, ABI-breaking changes mean the EPAS-server-devel package now requires clang-devel/llvm-devel versions that aren't available in the repositories. As a result, tpaexec download-packages and package installation during deploy failed for EPAS clusters on RedHat and SLES, with errors such as nothing provides (llvm-devel >= 20 with llvm-devel < 21) needed by edb-asNN-server-devel.

The -server-devel package has been removed from the default EPAS package list for RedHat and SLES. These packages are only needed to build Postgres extensions from source and aren't required by EDB products, so normal deployments are unaffected. If you still need them, you can add them explicitly via postgres_packages in the cluster configuration.

Changes made in TPA 23.44.0 to bump the versions of edb-python andedb-python-mod_wsgi to meet the requirements of PEM 10.4 didn't ensure that the new WSGI module was enabled, resulting in the Apache web server being unable to start on Debian-like platforms, where explicit activation is required. This fix resolves that issue by using the same fact for both package installation and module activation. This fix also resolves a related issue where PEM server upgrade could fail because the Apache configuration was transiently invalid between the removal of an old WSGI module and the activation of a new one.

The "Ensure that connections through pgbouncer are TLS-protected" task connected to pgbouncer without an sslmode attribute. TPA configures pgbouncer with client_tls_sslmode = require, which rejects any client that doesn't initiate the SSL handshake. The task therefore failed withFATAL: SSL required on every pgbouncer-bearing cluster whenever an upgrade or tpaexec test run reached it, preventing upgrades from completing.

The TLS check now connects to the pgbouncer administrative database withsslmode=require. A successful connection is itself the proof that pgbouncer accepted a TLS-required client, and the test no longer depends on the operator's pgbouncer_databases containing a particular routable backend dbname.

The same test also verifies pgbouncer's backend host and port by looking up the pgbouncer_auth_database route in SHOW DATABASES. On clusters where the operator's pgbouncer_databases doesn't include that route — neither via the wildcard * nor an explicit entry — the lookup returned nothing and the test crashed. It now skips that check gracefully when the route isn't present, so upgrades can complete. To keep the check active on a customised configuration, add an explicit pgbouncer_auth_databaseentry to pgbouncer_databases.

Deploying a BDR or PGD cluster on SLES 15 aborted with The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'SUSE' while recording the primary BDR/PGD package name. The tasks that record this package name looked it up by OS family (SUSE) instead of by distribution (SLES), the key actually used in TPA's package lists, so the lookup failed and the play stopped before any BDR package was installed. These tasks now resolve the package name the same way as the rest of the package selection, and SLES deploys proceed as they do on RHEL and Debian.

When an etcd, haproxy, pgd-proxy or other TLS-enabled service shared a host with Patroni and Postgres, TPA could configure Postgres and Patroni to use another service's certificate and key instead of their own. This issue was most visible on an M1 cluster with Patroni whereetcd ran on the database nodes: the replicas were given the etcdcertificate (/etc/tpa/etcd/etcd.crt), which the postgres user cannot read, so Postgres failed to start. Setting the certificate paths explicitly in config.yml worked around the Postgres failure but then left the Patroni REST API using the same unreadable etcd certificate.

The certificate role no longer routes per-service certificate paths through the shared ssl_cert_file/ssl_key_file variables, so each service now uses its own certificate regardless of how roles are distributed across nodes. The documented ssl_cert_file andssl_key_file overrides for the Postgres server certificate continue to work as before; clusters that don't set them use the default Postgres certificate at /etc/tpa/<cluster_name>.crt.

A bug was found in the pem.conf file where pem_web_server_name pointed to an incorrect path. This issue has been corrected to ensure the right path is referenced where it is needed.

Fix contributed by skrzyzok (https://github.com/skrzyzok).

A dangling list item (a - with nothing after it) in an instance's role list parsed to an empty value and was carried through to the generated inventory, where it produced a spurious role_None Ansible group. Such empty entries are now dropped, and provision emits a warning so a stray - left over from hand-editing config.yml is easy to spot.

When EFM was chosen as the failover manager, PEM servers weren't excluded from cluster-replication tasks, which could cause issues with the replication topology and EFM role delegation during deployment. PEM servers are now excluded from these tasks in that configuration.

Two invocations were affected. pemworker --register-server was called with --cert-path, which has never been a valid option for that subcommand and is now removed unconditionally.

pemworker --enable-probe was called with --pem-user and--pem-port, which were silently required by PEM versions before 10.5 but are rejected by PEM 10.5 and later. TPA now omits these arguments when pem_agent_version is 10.5.0 or newer, and continues to pass them on older PEM versions where they remain necessary.

During a BDR 4 to PGD 5 upgrade, the pgdproxy user and other database roles created on data nodes weren't propagated to witness nodes. This issue happened because DDL replication doesn't reach witness nodes oncenode_kind='witness' is set, and the upgrade path didn't create the roles locally on the witness the way a fresh PGD 5 deployment would.

The upgrade process now parts the witness after the data node upgrade loop and rejoins it afterwards to sync the full catalog from the data nodes, ensuring the witness has the same database user list as a fresh PGD 5 deployment.

Volumes are per-instance settings and must be defined underinstance_defaults (as default_volumes) or on individual instances. When volumes or default_volumes were set in cluster_vars they were silently ignored, which on AWS resulted in instances being created with the default AMI root volume instead of the intended one. TPA now detects this misconfiguration and fails early with a message explaining where volumes should be defined.

Previously this misconfiguration could pass silently and lead to confusing downstream errors.

When efm_user_is_superuser wasn't present in a cluster's configuration file, it failed to resolve to its documented default oftrue, which could prevent redeployment of pre-existing clusters. The variable now correctly defaults to true when it isn't set.

TPA now checks whether the configuration used to create the cluster has a complete PEM role configuration whenever at least one pem-serverrole and at least one pem-agent role are present in config.yml. To allow a partial PEM configuration, add the pem-role-check task selector to the list of excluded tasks in the cluster configuration file; this fix bypasses the check and lets deployment continue with an incomplete PEM configuration, which may expose the cluster to failures later in the deployment.