Re: pg_primary_conninfo

On Tue, Dec 28, 2010 at 1:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> writes:
> > On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> >> SQL access is frequently more convenient, though. Although maybe now
> that
> >> we've made recovery.conf use the GUC lexer we oughta continue in that
> vein
> >> and expose those parameters as PGC_INTERNAL GUCs rather than inventing a
> new
> >> function for it...
>
> > +1 for SQL access, but exposing it via pg_settings opens up the security
> > problem as there might be sensitive info in those GUCs.
>
> IIRC we do have a GUC property that hides the value from non-superusers,
> so we could easily have a GUC that is equivalent to the proposed
> pg_primary_conninfo function. Of course this does nothing for my
> objections to the function. Also, I'm not sure how we'd deal with the
> state-dependency aspect of it (ie, value changes once you exit recovery
> mode).
>

I would vote for making host:port part visible to non-superusers. This info
is definitely usable in combination with pg_current_xlog_location() and
pg_last_xlog_receive_location() to allow non-superusers to monitor streaming
replication.

Given that primary_conninfo is already parsed by libpq, how difficult would
it be to extract and store/display those host:port components.

Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com

singh(dot)gurjeet(at){ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device