On Thu, 17 Jan 2019 at 19:15, Tatsuo Ishii <is...@sraoss.co.jp> wrote:
> > On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii <is...@sraoss.co.jp> wrote: > > > >> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii <is...@sraoss.co.jp> > wrote: > >> > > >> >> > 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. I'm curious; under what circumstances would the above occur? Regards, Dave
