> On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: > >> > From: Tatsuo Ishii [mailto:ishii@sraoss.co.jp] >> >> But pg_is_in_recovery() returns true even for a promoting standby. So >> >> you have to wait and retry to send pg_is_in_recovery() until it >> >> finishes the promotion to find out it is now a primary. I am not sure >> >> if backend out to be responsible for this process. If not, libpq would >> >> need to handle it but I doubt it would be possible. >> > >> > Yes, the application needs to retry connection attempts until success. >> That's not different from PgJDBC and other DBMSs. >> >> I don't know what PgJDBC is doing, however I think libpq needs to do >> more than just retrying. >> >> 1) Try to find a node on which pg_is_in_recovery() returns false. If >> found, then we assume that is the primary. We also assume that >> other nodes are standbys. done. >> >> 2) If there's no node on which pg_is_in_recovery() returns false, then >> we need to retry until we find it. To not retry forever, there >> should be a timeout counter parameter. >> >> > IIRC this is essentially what pgJDBC does.
Thanks for clarifying that. Pgpool-II also does that too. Seems like a common technique to find out a primary node.
Checking the code I see we actually use show transaction_read_only.
