Alexander Kukushkin

Well, yeah... We need to rethink the way of finding and identifying non-client backends...

@lifedanceman are you planning to work on it? If not, I will close the issue.

The replication user on the standby cluster should not be necessarily the same as used in the primary cluster, but the primary cluster must accept replication connection from the standby...

> If both standby leader and replicas pgpass files are taking the user and password from the same source I am not following what you are doing. Every Patroni node...

patronictl list is using DCS as a source and therefore doesn't show real-time information. In the worst case it could be outdated up to `loop_wait` seconds.

Hmm, I think we can do better job in verifying the state of the data directory. Most of the (good) backup tools will restore `global/pg_control` on the last step. Missing...

Interesting, it fails with `403 Forbidden`, not with 409... It shouldn't be so hard to fix it by doing an explicit check that service already exists.

Explicit is better than implicit. Basically it is your responsibility to provide a correct configuration (wal_level: logical). Also changing of wal_level requires a restart of postgres and Patroni will not...

> if bootstrap config is bad YAML, then Patroni refuses to start Not necessarily a bootstrap, but config in general. And this is an absolutely different issue. It is possible...

You can use environment variables https://patroni.readthedocs.io/en/latest/ENVIRONMENT.html#postgresql, but on Postgres v10+ Patroni will write replication password to pgpass anyway and reference it from the `primary_conninfo`.