Le 28/12/2010 17:36, Tom Lane a écrit :
> Guillaume Lelarge <guillaume@lelarge.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.
--
Guillaumehttp://www.postgresql.frhttp://dalibo.com