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 Dave Cramer da...@postgresintl.com www.postgresintl.com > >
