> On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: > >> > 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. > > Sorry for the confusion
So if all PostgreSQL servers returns transaction_read_only = on, how does pgJDBC find the primary node?
well preferSecondary would return a connection.
I'm curious; under what circumstances would the above occur?
