On Wed, Nov 16, 2016 at 12:00 PM, Catalin Iacob <iacobcata...@gmail.com> wrote:
> On Wed, Nov 16, 2016 at 2:50 PM, Robert Haas <robertmh...@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.
It seems like it is going to be difficult to please everyone here
100%, because there are multiple conflicting priorities. But we can
definitely document whatever choices we make.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
