From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Jing Wang <jingwangian(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Libpq support to connect to standby server as priority |
Date: | 2019-01-18 00:02:15 |
Message-ID: | CADK3HHLEdsTK9ytTQ+XQwgCwv7vptNrS-xpYBbk_MUQApSBEEg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Dave Cramer
davec(at)postgresintl(dot)com
www.postgresintl.com
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-01-18 00:03:27 | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) |
Previous Message | Tom Lane | 2019-01-17 23:57:36 | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) |