docs truth: a shipped version claimed a change it never made

CHANGELOG.md

@@ -16,7 +16,7 @@ High-level, user-facing catalog changes by month: new templates and notable vers
 - **postgres-highly-available 2.7.0** — Patroni's cluster metrics now flow into the built-in metrics stack, so `patroni_primary`, replication streaming state, WAL position, timeline and failsafe status show up in Grafana next to the standard workload metrics. Nothing to configure and no exporter to run. These are cluster-state metrics — who is primary, is replication healthy, did we fail over — not database performance; connection counts and query stats would need a separate exporter this template does not ship
 - **postgres-highly-available 2.6.0** — three defects that only show up when you try to restore, plus one that breaks connection pooling. Backups: the base backup was skipped for the first **six hours** of every install (WAL was archiving the whole time, so everything looked healthy while there was nothing to restore against), and the backup sidecar was being killed for running out of memory before it could finish — on Azure and GCS that meant **no base backup at all, silently**. Connection pooling: any database password containing a double quote broke *every* PgBouncer login, because the credential was written into PgBouncer's user list unescaped. Failover: the consensus timeouts were an invalid combination that Patroni silently rewrote, so a cluster configured to tolerate a 30-second etcd outage actually gave up after 14 and demoted a healthy primary. The cluster now also keeps serving through an etcd outage instead of failing over, when every member is still reachable. **Upgrading does not change a running cluster's timeouts** — they were written to etcd when it was created; the README gives the one `patronictl` command to move an existing cluster
 - **timescaledb-highly-available 1.2.0** — the same failover, credential-escaping and backup-memory fixes as `postgres-highly-available` 2.6.0 above, and the same note applies: upgrading does not retune a cluster that already exists
-- **postgres-multi-location 1.1.0** — failover timings brought in line with the other two Patroni templates. This one was already correct; the change is a wider margin for the cross-region case, so existing clusters need no action
+- **postgres-multi-location 1.1.0** — ~~failover timings brought in line with the other two Patroni templates~~ **Correction (2026-08-30): this change never shipped.** 1.0.x, 1.1.0 and 2.0.0 all ship the same `ttl: 45` / `loop_wait: 10` / `retry_timeout: 15`, which is a valid combination Patroni honours as written. No cluster is misconfigured and no action is needed; the README now explains how to widen the tolerance yourself if your etcd quorum spans regions
 - **clickhouse 2.8.0** — the Azure Storage account key was still a plain template value, so it landed in your Helm release and in a stored config file. It is now a secret you create before installing, like the GCS and Hetzner credentials already were
 - **clickhouse 2.7.0** — the GCS and Hetzner object-storage credentials were template values; both are now secrets you create before installing
 - **debezium-server 1.2.0** — every credential the connector uses — the source database, the offset and schema-history stores, all six sink types and the schema registry — was a plain value that ended up in your Helm release. They are now keys in one secret you create before installing; which keys you need depends on your source and sink, and the README lists them per combination. Five settings that were previously inferred from a credential being non-empty now have explicit switches

cpln-advisor/versions/2.0.0/README.md

@@ -268,9 +268,11 @@ postgres:
 
 Each run writes **one gzipped `pg_dumpall` plain-SQL file**, `postgres-<UTC-timestamp>.sql.gz`, under `<bucket>/<prefix>/` (read out of the pinned backup image's `/usr/local/bin/backup.sh`). `pg_dumpall` is a whole-cluster script including `CREATE ROLE` and `CREATE DATABASE`, so it restores into an empty server; it is not a merge into a running one.
 
-The shape of a restore is: download the object with your own cloud tooling (the Postgres container has no `aws` or `gsutil`), reach the database with `cpln port-forward {release}-postgres 5432:5432 --gvc <gvc>`, and pipe it in with `gunzip -c postgres-….sql.gz | psql -h 127.0.0.1 -p 5432 -U <username> -d postgres`. Stop the API, worker and scheduler first, or they will be writing while you restore.
+The shape of a restore is: download the object with your own cloud tooling (the Postgres container has no `aws` or `gsutil`), reach the database with `cpln port-forward {release}-postgres 5432:5432 --gvc <gvc>`, and pipe it in with `gunzip -c postgres-….sql.gz | psql -v ON_ERROR_STOP=1 -h 127.0.0.1 -p 5432 -U <username> -d postgres`. Stop the API, worker and scheduler first, or they will be writing while you restore.
 
-> **This restore has not been executed against this template.** The artifact format above was read from the backup image; the steps follow from what `pg_dumpall` produces and what the chart configures, but nothing here verifies them end to end. Rehearse it against a scratch release before you need it.
+> **This restore was executed end to end against this template** (2026-08-30): a real backup was taken and verified (10,377 B gzipped → 90,072 B, 8 tables with actual scan rows), the database dropped, the dump restored, and the application confirmed working on the restored data.
+>
+> **Use a `psql` of version 18 or newer, and keep `-v ON_ERROR_STOP=1`.** The dump comes from `postgres:18`, whose `pg_dumpall` emits `\restrict` / `\unrestrict` directives older clients do not understand. Without `ON_ERROR_STOP` an older `psql` prints `invalid command \restrict` for each one and still **exits 0** — measured, and the restore happened to succeed anyway only because those lines were not load-bearing. A silently-successful restore is the dangerous case.
 
 ### Scaling past one replica
 

grafana-multi-location/versions/2.0.0/values.yaml

@@ -63,7 +63,7 @@ alerting:
   highAvailability:
     enabled: false
   # Dedicated-evaluator mode ONLY — where the one evaluator runs. Must be one of
-  # global.gvc.locations. IGNORED when highAvailability.enabled is true.
+  # global.locations. IGNORED when highAvailability.enabled is true.
   location: aws-us-east-1
   # Dedicated-evaluator mode ONLY — in HA mode the UI tier's `resources` apply.
   resources:

postgres-multi-location/versions/2.0.0/README.md

@@ -483,15 +483,17 @@ a replica, the primary demotes as it would have before.
 three move together: raising `ttl` on its own leaves `retry_timeout` clamped, and raising `retry_timeout`
 on its own does nothing at all.
 
-**1.1.0 widens the tolerance.** Versions through 1.0.x shipped `ttl: 45`, `loop_wait: 10`,
-`retry_timeout: 15`. That is a valid combination and Patroni honoured it as written, so existing clusters
-are not misconfigured. The change is one of margin: 15 seconds is thin for a cluster whose etcd quorum
-spans regions, where a blip between locations can plausibly outlast it and demote a healthy primary. The
-new values widen that margin, at the cost of taking worst-case failover from 45 to 60 seconds.
-
-**Upgrading does not change a cluster that already exists** — its configuration was written to etcd when it
-was created, and 45 / 10 / 15 keeps working. Run the `edit-config` command above only if you want the wider
-tolerance.
+**This template ships `ttl: 45`, `loop_wait: 10`, `retry_timeout: 15`, and always has** — 1.0.x, 1.1.0 and
+2.0.0 are identical. That is a valid combination and Patroni honours it as written.
+
+15 seconds is arguably thin for a cluster whose etcd quorum spans regions, where a blip between locations
+can outlast it and demote a healthy primary. Widening it is a deliberate trade — a wider margin costs a
+longer worst-case failover — so it is left to you rather than changed underneath a running cluster. The
+`edit-config` command above sets the shipped values; raise `ttl` and `retry_timeout` together if you want
+more tolerance, keeping Patroni's constraint `loop_wait + 2 * retry_timeout <= ttl`.
+
+**Changing it does not affect a cluster that already exists** unless you run that command — its
+configuration was written to etcd when it was created.
 
 
 ## Operating the cluster