Re: Patch: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Patch: Implement failover on libpq connect level.
Date
Msg-id CA+TgmoZVxSoHt_4TJGW7kU9bNad5GX-n9C0-4zsm345665Qm8Q@mail.gmail.com
Whole thread Raw
In response to Re: Patch: Implement failover on libpq connect level.  (Mithun Cy <mithun.cy@enterprisedb.com>)
Responses Re: Patch: Implement failover on libpq connect level.  (Catalin Iacob <iacobcatalin@gmail.com>)
Re: Patch: Implement failover on libpq connect level.  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On Tue, Nov 15, 2016 at 11:31 PM, Mithun Cy <mithun.cy@enterprisedb.com> wrote:
>> > So I am tempted to just
>> > hold my nose and hard-code the SQL as JDBC is presumably already
>> doing.
>
> JDBC is sending "show transaction_read_only" to find whether it is master or
> not.
> Victor's patch also started with it, but later it was transformed into
> pg_is_in_recovery
> by him as it appeared more appropriate to identify the master / slave.

Hmm, let's go back to the JDBC method, then.  "show
transaction_read_only" will return true on a standby, but presumably
also on any other non-writable node.  You could even force it to be
true artificially if you wanted to force traffic off of a node, using
ALTER {SYSTEM|USER ...|DATABASE ..} SET default_transaction_read_only
= on

I think that would address Alvaro's concern, and it's nicer anyway if
libpq and JDBC are doing the same thing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Parallel execution and prepared statements
Next
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql: Build HTML documentation using XSLT stylesheets by default