Re: Patch: Implement failover on libpq connect level.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Mithun Cy <mithun.cy@enterprisedb.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Peter van Hardenberg <pvh@pvh.ca>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-11-16T13:50:22Z
Lists: 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
Commits
-
libpq: Add target_session_attrs parameter.
- 721f7bd3cbcc 10.0 landed
-
Remove superuser checks in pgstattuple
- fd321a1dfd64 10.0 cited
-
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
- c405918858c0 9.6.0 cited