>> >> >> > From: Tatsuo Ishii [mailto:is...@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. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
