Re: exposing pg_controldata and pg_config as functions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: exposing pg_controldata and pg_config as functions
Date
Msg-id 20160218083017.up6vz5l6cgb6hvid@alap3.anarazel.de
Whole thread Raw
In response to Re: exposing pg_controldata and pg_config as functions  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: exposing pg_controldata and pg_config as functions
Re: exposing pg_controldata and pg_config as functions
List pgsql-hackers
On 2016-02-17 21:19:08 -0500, Peter Eisentraut wrote:
> On 2/17/16 9:08 PM, Michael Paquier wrote:
> > On Thu, Feb 18, 2016 at 11:02 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> >> On 2/17/16 5:20 PM, Josh berkus wrote:
> >>> I have a use-case for this feature, at part of it containerized
> >>> PostgreSQL. Right now, there is certain diagnostic information (like
> >>> timeline) which is exposed ONLY in pg_controldata.
> >>
> >> I'm talking about the pg_config() function, not pg_controldata.
> > 
> > Andrew has mentioned a use case he had at the beginning of this thread
> > to enhance a bit the regression tests related to libxml.
> 
> While that idea was useful, I think we had concluded that there are
> better ways to do this and that this way probably wouldn't even work
> (Windows?).

I don't understand why you're so opposed to this. Several people said
that they're interested in this information in the current discussion
and it has been requested repeatedly over the years. For superusers you
can already hack access, but it's darn ugly.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pg_ctl promote wait
Next
From: Andres Freund
Date:
Subject: Re: pg_ctl promote wait