admin
aa87f11588
Root cause of the "Canary row did not propagate" Phase 3 failure (run #7): legacy's pg_hba.conf requires scram-sha-256 for any non-local connection, and every remote `psql -h <patroni-node>` call in this script had never supplied a password at all. This was masked until the prior stderr-capture fix (run #7) surfaced the real error: "fe_sendauth: no password supplied" on every single attempt. patroni-0/patroni-1 use the SAME PGadmin superuser + SAME postgresql_password secret as legacy itself (per postgresql-ha-staging.yaml), so the fix reads that secret once via `docker exec "$LEGACY_CID" cat /run/secrets/postgresql_password` early in Phase 3, then passes it to every remote psql call via `docker exec -e PGPASSWORD=...` (not spliced into the bash -c string, to avoid quoting hazards). Found and fixed the identical missing-password pattern in THREE places, all with the same root cause: - Phase 3: the canary-propagation SELECT (where it was first caught) - Phase 5: the post-promotion pg_is_in_recovery() check - Phase 8: the alias write + both leader/replica visibility checks Added "2026 run #8" entry to the script's own header FIX LOG. Not yet re-validated by a run reaching past Phase 3. See ADR-0001 note, Session Update 11 (to be added).