On Mon, Nov 14, 2016 at 2:38 AM, Mithun Cy <mithun...@enterprisedb.com> wrote: > On Fri, Nov 11, 2016 at 7:33 PM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
