>> >> >> > 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.
This is not my message :-)
> I'm curious; under what circumstances would the above occur?
Former primary goes down and one of standbys is promoting but it is not promoted to new primary yet.
seems like JDBC might have some work to do...Thanks
I'm going to wait to implement until we resolve this discussion
