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: 4D1A13A0.7090709@lelarge.info (view raw or flat)
Thread:
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
current_setting().

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.


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com

In response to

Responses

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-2014 The PostgreSQL Global Development Group