Re: Patch: Implement failover on libpq connect level.

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Peter van Hardenberg <pvh(at)pvh(dot)ca>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: Implement failover on libpq connect level.
Date: 2016-11-15 14:42:31
Message-ID: 20161115144231.ptqqujkln36zem5r@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

Robert Haas wrote:
> On Mon, Nov 14, 2016 at 2:38 AM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> wrote:

> > 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).

I would rather come up with something that works in both cases that we
can extend internally later, say pg_is_primary_node() or something like
that instead; and we implement it initially by returning the inverse of
pg_is_in_recovery() for replicated non-logical flocks, while we figure
out what to do in logical replication. Otherwise it will be harder to
change later if we embed it in libpq, and we may be forced into
supporting nonsensical situations such as having pg_is_in_recovery()
return true for logical replication primary nodes.

FWIW I'm not sure "primary" is the right term here either. I think what
we really want to know is whether the node can accept writes; maybe
"pg_is_writable_node".

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-11-15 14:44:54 Re: A bug in UCS_to_most.pl
Previous Message Robert Haas 2016-11-15 14:36:46 Re: Patch: Implement failover on libpq connect level.

Browse pgsql-jdbc by date

  From Date Subject
Next Message Robert Haas 2016-11-15 16:58:18 Re: Patch: Implement failover on libpq connect level.
Previous Message Robert Haas 2016-11-15 14:36:46 Re: Patch: Implement failover on libpq connect level.