Re: Patch: Implement failover on libpq connect level.
От | Robert Haas |
---|---|
Тема | Re: Patch: Implement failover on libpq connect level. |
Дата | |
Msg-id | CA+TgmoZVxSoHt_4TJGW7kU9bNad5GX-n9C0-4zsm345665Qm8Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch: Implement failover on libpq connect level. (Mithun Cy <mithun.cy@enterprisedb.com>) |
Ответы |
Re: Patch: Implement failover on libpq connect level.
Re: Patch: Implement failover on libpq connect level. |
Список | 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 по дате отправления: