RE: Libpq support to connect to standby server as priority

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

In response to

Responses

Browse pgsql-hackers by date

  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