Re: Libpq support to connect to standby server as priority

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: pg(at)fastcrypt(dot)com
Cc: ishii(at)sraoss(dot)co(dot)jp, tsunakawa(dot)takay(at)jp(dot)fujitsu(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
Date: 2019-01-17 23:03:20
Message-ID: 20190118.080320.2079320832609473046.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikael Kjellström 2019-01-17 23:10:01 Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD
Previous Message Mikael Kjellström 2019-01-17 23:00:49 Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD