| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'Tatsuo Ishii' <ishii(at)sraoss(dot)co(dot)jp> |
| Cc: | "pg(at)fastcrypt(dot)com" <pg(at)fastcrypt(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "laurenz(dot)albe(at)cybertec(dot)at" <laurenz(dot)albe(at)cybertec(dot)at>, "kommi(dot)haribabu(at)gmail(dot)com" <kommi(dot)haribabu(at)gmail(dot)com>, "jingwangian(at)gmail(dot)com" <jingwangian(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: Libpq support to connect to standby server as priority |
| Date: | 2019-01-16 08:26:28 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1FB68602@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Tatsuo Ishii [mailto:ishii(at)sraoss(dot)co(dot)jp]
> 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.
It may be convenient for libpq to be able to retry connection attempts for a specified duration (by failover_timeout or such), because it eliminates the need for the application to do the retry. But I think it's a desirable feature, not a required one.
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-01-16 08:27:05 | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |
| Previous Message | Peter Eisentraut | 2019-01-16 08:26:10 | Re: [HACKERS] generated columns |