Horton

Re: Patch: Implement failover on libpq connect level.

Catalin Iacob <iacobcatalin@gmail.com>

View thread View on postgr.es
From: Catalin Iacob <iacobcatalin@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Mithun Cy <mithun.cy@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Peter van Hardenberg <pvh@pvh.ca>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-11-16T17:00:42Z
Lists: pgsql-hackers 
On Wed, Nov 16, 2016 at 2:50 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

Not sure I agree that using this is a good idea in the first place.

But if we end up using this, I really think the docs should be very
explicit about what's implemented and not just say master/any. With
the master/any docs in the patch I would be *very* surprised if a
master is skipped only because it was configured with
default_transaction_read_only = on.

Commits

  1. libpq: Add target_session_attrs parameter.

  2. Remove superuser checks in pgstattuple

  3. Fix unwanted flushing of libpq's input buffer when socket EOF is seen.