Re: Patch: Implement failover on libpq connect level.

On Mon, Nov 14, 2016 at 2:38 AM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> wrote:
> On Fri, Nov 11, 2016 at 7:33 PM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> We tend to use the term "primary" instead of "master".
>
> Thanks, I will use primary instead of master in my next patch.
>
>>Will this work with logical replication?
>
> I have not tested with logical replication. Currently we identify the
> primary to connect based on result of "SELECT pg_is_in_recovery()". So I
> think it works. Do you want me test a particular setup?

If logical replication is in use, none of the servers involved would
be in recovery. I'm not sure what command would need to be used to
assess whether we've got a master or a standby, but probably not that
one. This gets at one of my earlier complaints about this part of the
functionality, which is that hardcoding that particular SQL statement
into libpq seems like a giant hack. However, I'm not sure what to do
about it. The functionality is clearly useful, because JDBC has it,
and Victor proposed this patch to add it to libpq, and - totally
independently of any of that - EnterpriseDB has a customer who has
requested libpq support for this as well. So I am tempted to just
hold my nose and hard-code the SQL as JDBC is presumably already
doing. If we figure out what the equivalent for logical replication
would be we can add something to cover that case, too. It's ugly, but
I don't have a better idea, and I think there's value in being
compatible with what JDBC has already done (even if it's not what we
would have chosen to do tabula rasa).

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