On Tue, Dec 28, 2010 at 1:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Gurjeet Singh <singh.gurj...@gmail.com> writes: > > On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas <robertmh...@gmail.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.gurj...@{ gmail | yahoo }.com Twitter/Skype: singh_gurjeet Mail sent from my BlackLaptop device
