Re: [HACKERS] Patch: Implement failover on libpq connect level. - Mailing list pgsql-jdbc

From Craig Ringer
Subject Re: [HACKERS] Patch: Implement failover on libpq connect level.
Date
Msg-id CAMsr+YF6Zt7Jcs4PUEx=ovMcdo0wYbseshgVrqgukYj9KtmRBw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Patch: Implement failover on libpq connect level.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Patch: Implement failover on libpq connect level.
Re: [HACKERS] Patch: Implement failover on libpq connectlevel.
List pgsql-jdbc
On 16 November 2016 at 23:13, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Nov 16, 2016 at 9:02 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
>> [moving this branch of discussion to pgsql-jdbc]
>>
>> On Tue, Nov 15, 2016 at 10:31 PM, Mithun Cy <mithun.cy@enterprisedb.com> wrote:
>>
>>> JDBC is sending "show transaction_read_only" to find whether it
>>> is master or not.
>>
>> If true, that's insane.  That can be different on each connection
>> to the cluster and can change tens of thousands of times per second
>> on any connection!
>
> I don't think that's insane.  The command is only being issued at
> connection startup, and will only be different on different
> connections if it's been configured that way.

I agree. However, I also think we should make sure add a GUC_REPORT
var in v10 that lets a client tell whether it's connected to a
read/write or read-only node right from the start. This will save an
unnecessary round-trip and some annoying log-spam.

I'd rather not bind it directly to "in recovery" because we're likely
to want to support read-only logical replication nodes in future, but
even that would be OK.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-jdbc by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Patch: Implement failover on libpq connect level.
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: [HACKERS] Patch: Implement failover on libpq connect level.