Le 28/12/2010 17:36, Tom Lane a écrit : > Guillaume Lelarge <guilla...@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. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
