|From:||Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>|
|Cc:||ishii(at)sraoss(dot)co(dot)jp, pg(at)fastcrypt(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, robertmhaas(at)gmail(dot)com, laurenz(dot)albe(at)cybertec(dot)at, kommi(dot)haribabu(at)gmail(dot)com, jingwangian(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: Libpq support to connect to standby server as priority|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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.
SRA OSS, Inc. Japan
|Next Message||Amit Langote||2019-01-16 06:22:26||Re: speeding up planning with partitions|
|Previous Message||Etsuro Fujita||2019-01-16 05:59:15||Re: de-deduplicate code in DML execution hooks in postgres_fdw|