Re: Libpq support to connect to standby server as priority

On Thu, 17 Jan 2019 at 19:15, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:

> > On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:
> >
> >> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
> wrote:
> >> >
> >> >> > From: Tatsuo Ishii [mailto:ishii(at)sraoss(dot)co(dot)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