On Tue, Nov 15, 2016 at 9:42 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> On Mon, Nov 14, 2016 at 2:38 AM, Mithun Cy <mithun...@enterprisedb.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.
I don't think we'll be backed into a corner like that, because we can always make this contingent on server version. libpq will have that available. -- 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
