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 05:41:03 |
Message-ID: | 0A3221C70F24FB45833433255569204D1FB683ED@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]
> 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.
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2019-01-16 05:41:47 | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |
Previous Message | Tatsuo Ishii | 2019-01-16 05:20:16 | Re: pgbench doc fix |