Skip site navigation (1) Skip section navigation (2)

Re: pg_primary_conninfo

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_primary_conninfo
Date: 2010-12-28 16:43:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Le 28/12/2010 17:36, Tom Lane a écrit :
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
>> Le 28/12/2010 16:34, Tom Lane a écrit :
>>> I'm still wondering what's the actual use-case for exposing this inside
>>> SQL.  Those with a legitimate need-to-know can look at the slave
>>> server's config files, no?
>> This is something I wanted to have in 9.0 when I coded in pgAdmin some
>> features related to the HotStandby. Knowing on which IP is the master
>> can help pgAdmin offer the user to register the master node.
>> It's also interesting to get lag between master and slave. As soon as
>> I'm connected to a slave, I can connect to the master and get the lag
>> between them. Something I can't do right now in pgAdmin.
> The proposed primary_conninfo seems like a pretty awful solution to
> those problems, though.

I would say "not the best one, but better than what I have now" :)

> 1. It'll have to be restricted to superusers, therefore ordinary
> users on the slave can't actually make use of it.

pgAdmin's users usually connect as superusers.

> 2. It's not what you want, since you don't want to connect as the
> replication user.  Therefore, you'd have to start by parsing out
> the parts you do need.  Expecting every client to include conninfo
> parsing logic doesn't seem cool to me.
> I can see the point of, say, a primary_host_address() function returning
> inet, which would be way better on both those dimensions than the
> current proposal.  But I'm not sure what else would be needed.

Yeah, it would be better that way. I'm actually interested in Magnus's
patch because, during 9.0 development phase, I had in mind to parse the
primary_conninfo till I found I could not get this value with SHOW or

But, actually, what I really need is host and port. This way, I could
connect to the master node, with the same user and password that was
used on the slave node.


In response to


pgsql-hackers by date

Next:From: Gurjeet SinghDate: 2010-12-28 16:50:24
Subject: Re: pg_primary_conninfo
Previous:From: Joel JacobsonDate: 2010-12-28 16:41:04
Subject: Re: pg_dump --split patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group