There is assumption that the "sync" and "async" standby can be assigned by the client script, which isn't correct. Postgres chooses the sync standby automatically. So, when failing over, the procedure should be to fetch the /health of each standby, compare the replication log position, and choose the one that's more advanced. There may also be a tie, in which case either can be used.
assumptions dropped. pods are still labeled but only as: unset, master, standby & (during failover) candidate. candidate is selected per max repl log bytes.
There is assumption that the "sync" and "async" standby can be assigned by the client script, which isn't correct. Postgres chooses the sync standby automatically. So, when failing over, the procedure should be to fetch the
/health
of each standby, compare the replication log position, and choose the one that's more advanced. There may also be a tie, in which case either can be used.