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

Re: pg_primary_conninfo

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_primary_conninfo
Date: 2010-12-29 08:33:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Dec 28, 2010 at 17:43, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
> 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 :
>> 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.

It would be a function for DBAs, of course. I don't see why "normal
users" would be intersted in it, really.

>> 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.

I agree it might well be more useful to have it split up for us. We'd
need the host name (though it would have to be text and not inet,
since we'd need the unix socket path for a local connection) and port.
And username. But certainly not password, and probably none of the
other parameters.

 Magnus Hagander

In response to

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-12-29 08:36:03
Subject: Re: pg_primary_conninfo
Previous:From: Mark KirkwoodDate: 2010-12-29 08:16:29
Subject: Re: "writable CTEs"

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