Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/28/2016 07:45 PM, Michael Paquier wrote: > On Mon, Feb 29, 2016 at 3:50 AM, Joe Conway wrote: >> If there are no other complaints or comments, I will commit the attached >> sometime this coming week (the the requisite catversion bump). > > Thanks for the updated patch,

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Mon, Feb 29, 2016 at 3:50 AM, Joe Conway wrote: > If there are no other complaints or comments, I will commit the attached > sometime this coming week (the the requisite catversion bump). Thanks for the updated patch, I have nothing else to say on my side. The new version

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/28/2016 05:16 AM, Michael Paquier wrote: > +Returns information about current controldata file state. > s/controldata/control data? > > + > + > + > + Column Name > + Data Type > + > + > + > Having a description of each field would be nice.

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sun, Feb 28, 2016 at 9:33 AM, Joe Conway wrote: > On 02/21/2016 05:30 AM, Michael Paquier wrote: >> Looking again at this thread I guess that this is consensus, based on >> the proposal from Josh and seeing no other ideas around. Another idea >> would be to group all the

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/21/2016 05:30 AM, Michael Paquier wrote: > Looking again at this thread I guess that this is consensus, based on > the proposal from Josh and seeing no other ideas around. Another idea > would be to group all the fields that into a single function > pg_control_data(). I think a single

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sat, Feb 20, 2016 at 12:12 PM, Joe Conway wrote: > On 01/17/2016 04:10 PM, Joe Conway wrote: >> On 01/16/2016 06:02 AM, Michael Paquier wrote: >>> On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: 3) Adds new functions, more or less in line with

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/17/2016 04:10 PM, Joe Conway wrote: > On 01/16/2016 06:02 AM, Michael Paquier wrote: >> On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: >>> 3) Adds new functions, more or less in line with previous discussions: >>>* pg_checkpoint_state() >>>*

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Fri, Feb 19, 2016 at 11:53 AM, Peter Eisentraut wrote: > On 2/18/16 12:20 PM, Joe Conway wrote: >> Just to be clear, AFAIK there is no issue with the committed changes on >> Windows. If there is please provide a concrete example that we can discuss. > > Originally it was

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2/18/16 12:20 PM, Joe Conway wrote: > Just to be clear, AFAIK there is no issue with the committed changes on > Windows. If there is please provide a concrete example that we can discuss. Originally it was mentioned that this feature could be used in the regression tests by making certain

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2/18/16 3:30 AM, Andres Freund wrote: > 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. I think no one except Andrew Dunstan has requested this,

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/18/2016 12:30 AM, Andres Freund wrote: > 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 wrote: On 2/17/16 5:20 PM, Josh berkus wrote: > I have a use-case for

Re: [HACKERS] exposing pg_controldata and pg_config as functions

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 wrote: > >> On 2/17/16 5:20 PM, Josh berkus wrote: > >>> I have a use-case for this feature, at part of it containerized > >>>

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2/17/16 9:08 PM, Michael Paquier wrote: > On Thu, Feb 18, 2016 at 11:02 AM, Peter Eisentraut 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

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Thu, Feb 18, 2016 at 11:02 AM, Peter Eisentraut 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

Re: [HACKERS] exposing pg_controldata and pg_config as functions

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

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/17/2016 03:34 PM, Josh berkus wrote: > On 02/17/2016 03:02 PM, Tom Lane wrote: >> Joe Conway writes: >>> On 02/17/2016 02:14 PM, Tom Lane wrote: I thought we'd agreed on requiring superuser access for this function. I concur that letting just anyone see the

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/17/2016 03:02 PM, Tom Lane wrote: Joe Conway writes: On 02/17/2016 02:14 PM, Tom Lane wrote: I thought we'd agreed on requiring superuser access for this function. I concur that letting just anyone see the config data is inappropriate. It does not let anyone see

Re: [HACKERS] exposing pg_controldata and pg_config as functions

Joe Conway writes: > On 02/17/2016 02:14 PM, Tom Lane wrote: >> I thought we'd agreed on requiring superuser access for this function. >> I concur that letting just anyone see the config data is inappropriate. > It does not let anyone see config data out of the box: > +

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/17/2016 05:14 PM, Tom Lane wrote: Peter Eisentraut writes: On 2/17/16 12:15 PM, Joe Conway wrote: Ok, removed the documentation on the function pg_config() and pushed. I still have my serious doubts about this, especially not even requiring superuser access for this

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/17/2016 01:31 PM, Peter Eisentraut wrote: On 1/31/16 7:34 AM, Michael Paquier wrote: I am marking this patch as returned with feedback for now, not all the issues have been fixed yet, and there are still no docs (the conclusion being that people would like to have this stuff, right?).

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/17/2016 02:14 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 2/17/16 12:15 PM, Joe Conway wrote: >>> Ok, removed the documentation on the function pg_config() and pushed. > >> I still have my serious doubts about this, especially not even requiring >> superuser

Re: [HACKERS] exposing pg_controldata and pg_config as functions

Peter Eisentraut writes: > On 2/17/16 12:15 PM, Joe Conway wrote: >> Ok, removed the documentation on the function pg_config() and pushed. > I still have my serious doubts about this, especially not even requiring > superuser access for this information. Could someone explain

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2/17/16 12:15 PM, Joe Conway wrote: > On 02/17/2016 02:32 AM, Michael Paquier wrote: >> Actually, having second-thoughts on the matter, why is is that >> necessary to document the function pg_config()? The functions wrapping >> a system view just have the view documented, take for example >>

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 1/31/16 7:34 AM, Michael Paquier wrote: > I am marking this patch as returned with feedback for now, not all the > issues have been fixed yet, and there are still no docs (the > conclusion being that people would like to have this stuff, right?). > Feel free to move it to the next CF should a

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/17/2016 02:32 AM, Michael Paquier wrote: > Actually, having second-thoughts on the matter, why is is that > necessary to document the function pg_config()? The functions wrapping > a system view just have the view documented, take for example > pg_show_all_file_settings,

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Wed, Feb 17, 2016 at 10:13 AM, Michael Paquier wrote: > On Tue, Feb 16, 2016 at 11:36 PM, Joe Conway wrote: >> Thanks! > > OK. I think I'm good now. Thanks for the quick update. Actually, having second-thoughts on the matter, why is is that

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Tue, Feb 16, 2016 at 11:36 PM, Joe Conway wrote: > Thanks! OK. I think I'm good now. Thanks for the quick update. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/15/2016 11:20 PM, Michael Paquier wrote: > Here are just a couple of cosmetic comments. > Missing markup around PostgreSQL. Added, but I'll note that there are tons of locations in the docs where we do not do that. Maybe they should all be made consistent. > + Application. There is a

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Tue, Feb 16, 2016 at 5:29 AM, Joe Conway wrote: > I believe this takes care of all open issues with this, so I plan to > commit it as attached in a day or two. Thanks for your reviews and comments! Here are just a couple of cosmetic comments. + The view pg_config

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/20/2016 08:08 PM, Michael Paquier wrote: > On Wed, Jan 20, 2016 at 2:32 AM, Joe Conway wrote: >> The only things I know of still lacking is: >> 1) Documentation Done and included in the attached. >> 2) Decision on REVOKE ... FROM PUBLIC > > Yep, regarding 2) I am the

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On 02/11/2016 04:59 PM, Michael Paquier wrote: > On Fri, Feb 12, 2016 at 9:18 AM, Bruce Momjian wrote: >> No, that is not an improvement --- see my previous comment: >> >>> We could get more sophisticated by checking the catalog version number >>> where the format was changed,

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On Thu, Feb 11, 2016 at 07:18:46PM -0500, Bruce Momjian wrote: > No, that is not an improvement --- see my previous comment: > > > We could get more sophisticated by checking the catalog version number > > where the format was changed, but that doesn't seem worth it, and is > > overly complex

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On Sat, Feb 13, 2016 at 7:54 AM, Bruce Momjian wrote: > On Thu, Feb 11, 2016 at 07:18:46PM -0500, Bruce Momjian wrote: >> No, that is not an improvement --- see my previous comment: >> >> > We could get more sophisticated by checking the catalog version number >> > where the

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On Wed, Feb 10, 2016 at 10:23:41AM +0900, Michael Paquier wrote: > On Wed, Feb 10, 2016 at 9:57 AM, Joe Conway wrote: > > I'll commit the attached tomorrow if there are no other concerns voiced. > > Just a nitpick regarding this block: > + if (strchr(p, '/') !=

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On Fri, Feb 12, 2016 at 9:18 AM, Bruce Momjian wrote: > On Wed, Feb 10, 2016 at 10:23:41AM +0900, Michael Paquier wrote: >> On Wed, Feb 10, 2016 at 9:57 AM, Joe Conway wrote: >> > I'll commit the attached tomorrow if there are no other concerns voiced. >> >>

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On 01/19/2016 07:04 PM, Michael Paquier wrote: > On Wed, Jan 20, 2016 at 11:41 AM, Alvaro Herrera > wrote: >> Joe Conway wrote: >> >>> The attached includes Bruce's change, plus I found two additional sites >>> that appear to need the same change. The xlog.c change is

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On Wed, Feb 10, 2016 at 9:57 AM, Joe Conway wrote: > I'll commit the attached tomorrow if there are no other concerns voiced. Just a nitpick regarding this block: + if (strchr(p, '/') != NULL) + p = strchr(p, '/'); + /* delimiter changed from

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Thu, Jan 21, 2016 at 1:08 PM, Michael Paquier wrote: > On Wed, Jan 20, 2016 at 2:32 AM, Joe Conway wrote: >> The only things I know of still lacking is: >> 1) Documentation >> 2) Decision on REVOKE ... FROM PUBLIC > > Yep, regarding 2) I am the

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Wed, Jan 20, 2016 at 2:32 AM, Joe Conway wrote: > The only things I know of still lacking is: > 1) Documentation > 2) Decision on REVOKE ... FROM PUBLIC Yep, regarding 2) I am the only one actually making noise to protect this information by default, against at least 2

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

Joe Conway wrote: > The attached includes Bruce's change, plus I found two additional sites > that appear to need the same change. The xlog.c change is just a DEBUG > message, so not a big deal. I'm less certain if the xlogdesc.c change > might create some fallout. Hm, pg_xlogdump links the

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On Wed, Jan 20, 2016 at 11:41 AM, Alvaro Herrera wrote: > Joe Conway wrote: > >> The attached includes Bruce's change, plus I found two additional sites >> that appear to need the same change. The xlog.c change is just a DEBUG >> message, so not a big deal. I'm less

NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On 01/19/2016 09:02 AM, Bruce Momjian wrote: > Ok. Notwithstanding Simon's reply, there seems to be consensus that this > is the way to go. Will commit it this way unless some additional > objections surface in the next day or so. FYI, this slash-colon change will break

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Mon, Jan 18, 2016 at 07:50:12PM -0500, Bruce Momjian wrote: > > 1) Change NextXID output format from "%u/%u" to "%u:%u" > > (see recent hackers thread) > > >>> > > >>> ! printf(_("Latest checkpoint's NextXID: %u/%u\n"), > > >>>

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Mon, Jan 18, 2016 at 7:42 PM, Michael Paquier wrote: >> Yeah, I really don't see anything in the pg_controldata output that >> looks sensitive. The WAL locations are the closest of anything, >> AFAICS. > > The system identifier perhaps? I honestly don't have on top

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/18/2016 08:51 PM, Michael Paquier wrote: > On Tue, Jan 19, 2016 at 1:49 PM, Michael Paquier >> + } >> + >> + /* >> +* no longer need the tuple descriptor reference created by >> The patch has some whitespaces. I take it you mean a line with only whitespace? Fixed. >>

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2016-01-18 10:18:34 +0900, Michael Paquier wrote: > We are trying to hide away from non-superusers WAL-related information > in system views and system function, that's my point to do the same > here. We are? pg_current_xlog_insert_location(), pg_current_xlog_location(),

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/18/2016 04:16 PM, Joe Conway wrote: > Please see the attached. Duplication removed. Actually please see this version instead. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development diff --git

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Tue, Jan 19, 2016 at 6:55 AM, Robert Haas wrote: > On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund wrote: >> On 2016-01-18 10:18:34 +0900, Michael Paquier wrote: >>> We are trying to hide away from non-superusers WAL-related information >>> in system

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/17/2016 02:29 PM, Joe Conway wrote: >> Documentation would be good to have. > > I'm definitely happy to write the docs, but earlier it was not clear > that there was enough support for this patch at all, and I don't want to > waste cycles writing docs for a feature that ultimately does not

Re: [HACKERS] exposing pg_controldata and pg_config as functions

fOn Mon, Jan 18, 2016 at 01:54:02PM -0800, Joe Conway wrote: > On 01/18/2016 01:47 PM, Bruce Momjian wrote: > > On Sun, Jan 17, 2016 at 02:24:46PM -0800, Joe Conway wrote: > >> On 01/16/2016 06:02 AM, Michael Paquier wrote: > >>> On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Tue, Jan 19, 2016 at 1:49 PM, Michael Paquier wrote: > On Tue, Jan 19, 2016 at 11:08 AM, Joe Conway wrote: >> On 01/18/2016 04:16 PM, Joe Conway wrote: >>> Please see the attached. Duplication removed. >> >> Actually please see this version

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Tue, Jan 19, 2016 at 11:08 AM, Joe Conway wrote: > On 01/18/2016 04:16 PM, Joe Conway wrote: >> Please see the attached. Duplication removed. > > Actually please see this version instead. Thanks for the new patch. + tuplestore_puttuple(tupstore, tuple); +

Re: [HACKERS] exposing pg_controldata and pg_config as functions

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund wrote: > > Meh, that seems pretty far into pseudo security arguments. > > Yeah, I really don't see anything in the pg_controldata output that > looks sensitive. The WAL locations

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/18/2016 01:47 PM, Bruce Momjian wrote: > On Sun, Jan 17, 2016 at 02:24:46PM -0800, Joe Conway wrote: >> On 01/16/2016 06:02 AM, Michael Paquier wrote: >>> On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: 1) Change NextXID output format from "%u/%u" to "%u:%u"

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund wrote: > On 2016-01-18 10:18:34 +0900, Michael Paquier wrote: >> We are trying to hide away from non-superusers WAL-related information >> in system views and system function, that's my point to do the same >> here. > > We are?

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On January 18, 2016 11:10:35 PM GMT+01:00, Stephen Frost wrote: >* Robert Haas (robertmh...@gmail.com) wrote: >> On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund >wrote: >> > Meh, that seems pretty far into pseudo security arguments. >> >> Yeah, I really

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sun, Jan 17, 2016 at 02:24:46PM -0800, Joe Conway wrote: > On 01/16/2016 06:02 AM, Michael Paquier wrote: > > On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: > >> 1) Change NextXID output format from "%u/%u" to "%u:%u" > >>(see recent hackers thread) > > > > !

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/16/2016 06:02 AM, Michael Paquier wrote: > On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: >> 1) Change NextXID output format from "%u/%u" to "%u:%u" >>(see recent hackers thread) > > ! printf(_("Latest checkpoint's NextXID: %u/%u\n"), >

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/16/2016 06:07 AM, Michael Paquier wrote: > On Sun, Dec 27, 2015 at 5:39 AM, Joe Conway wrote: >> First installment -- pg_config function/view as a separate patch, >> rebased to current master. > > Documentation would be good to have. I'm definitely happy to write the

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sun, Jan 17, 2016 at 8:48 AM, Andres Freund wrote: > On January 17, 2016 12:46:36 AM GMT+01:00, Michael Paquier > wrote: > , but we surely do not want to give away >>checkpoint and recovery information. > > Why is that? A lot of that information

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/16/2016 06:02 AM, Michael Paquier wrote: > On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: >> 3) Adds new functions, more or less in line with previous discussions: >>* pg_checkpoint_state() >>* pg_controldata_state() >>* pg_recovery_state() >>*

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sun, Dec 27, 2015 at 5:39 AM, Joe Conway wrote: > First installment -- pg_config function/view as a separate patch, > rebased to current master. Documentation would be good to have. ! # don't include subdirectory-path-dependent -I and -L switches ! STD_CPPFLAGS :=

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sat, Jan 16, 2016 at 11:07 PM, Michael Paquier wrote: > On Sun, Dec 27, 2015 at 5:39 AM, Joe Conway wrote: >> First installment -- pg_config function/view as a separate patch, >> rebased to current master. > > Documentation would be good to have.

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: > 1) Change NextXID output format from "%u/%u" to "%u:%u" >(see recent hackers thread) ! printf(_("Latest checkpoint's NextXID: %u/%u\n"), ControlFile.checkPointCopy.nextXidEpoch,

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On January 17, 2016 12:46:36 AM GMT+01:00, Michael Paquier wrote: , but we surely do not want to give away >checkpoint and recovery information. Why is that? A lot of that information is available anyway? --- Please excuse brevity and formatting - I am writing this

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Jan 16, 2016, at 9:08 AM, Michael Paquier wrote: > Just forgot to mention that those new functions should be superuser-only. I think nobody should ever say this without explaining why. Superuser restrictions are necessary in some cases, but the fewer of them we

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 12/23/2015 04:37 PM, Michael Paquier wrote: > On Thu, Dec 24, 2015 at 2:08 AM, Joe Conway wrote: >> 2) Change the pg_controldata to be a bunch of separate functions as >>suggested by Josh Berkus rather than one SRF. > > This looks like a plan, thanks! As discussed, a

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 12/23/2015 04:37 PM, Michael Paquier wrote: > On Thu, Dec 24, 2015 at 2:08 AM, Joe Conway wrote: >> On 12/23/2015 05:45 AM, Michael Paquier wrote: Yeah, the last version of the patch dates of August, and there is visibly agreement that the information of

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Wed, Dec 9, 2015 at 9:18 PM, Michael Paquier wrote: > On Thu, Sep 17, 2015 at 7:12 AM, Andres Freund wrote: >> On 2015-08-20 09:59:25 -0400, Andrew Dunstan wrote: >>> Is there any significant interest in either of these? >>> >>> Josh Berkus tells

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 12/23/2015 05:45 AM, Michael Paquier wrote: >> Yeah, the last version of the patch dates of August, and there is >> visibly agreement that the information of pg_controldata provided at >> SQL level is useful while the data of pg_config is proving to be less >> interesting for remote users.

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Thu, Dec 24, 2015 at 2:08 AM, Joe Conway wrote: > On 12/23/2015 05:45 AM, Michael Paquier wrote: >>> Yeah, the last version of the patch dates of August, and there is >>> visibly agreement that the information of pg_controldata provided at >>> SQL level is useful while the

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Thu, Sep 17, 2015 at 7:12 AM, Andres Freund wrote: > On 2015-08-20 09:59:25 -0400, Andrew Dunstan wrote: >> Is there any significant interest in either of these? >> >> Josh Berkus tells me that he would like pg_controldata information, and I >> was a bit interested in

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 10/30/2015 06:53 AM, Erik Rijkers wrote: >> [2015082503-pgconfig_controldata.diff] > > I tried to build this, and the patch applies cleanly but then a ld error > emerges: I'm sure the patch would need to be rebased, but the last thread died with significant complaints and questions about what

Re: [HACKERS] exposing pg_controldata and pg_config as functions

Erik Rijkers wrote: > utils/fmgrtab.o:(.rodata+0x19f78): undefined reference to `_null_' > utils/fmgrtab.o:(.rodata+0x1a078): undefined reference to `_null_' The fix for this is to add a parallel-safe flag to new pg_proc.h lines. -- Álvaro Herrerahttp://www.2ndQuadrant.com/

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[2015082503-pgconfig_controldata.diff] I tried to build this, and the patch applies cleanly but then a ld error emerges: (The first four lines (about gram.y) are standard warnings; the error starts from the ld line) In file included from gram.y:14908:0: scan.c: In function

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2015-08-20 09:59:25 -0400, Andrew Dunstan wrote: > Is there any significant interest in either of these? > > Josh Berkus tells me that he would like pg_controldata information, and I > was a bit interested in pg_config information, for this reason: I had a > report of someone who had

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 9/8/15 4:56 PM, Andrew Dunstan wrote: > The problem is that at least this user's system had something odd about > it. so that I wouldn't entirely trust the output of > >select is_supported >from information_schema.sql_features >where feature_name = 'XML type'; > > to reflect the

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 9/7/15 7:32 PM, Alvaro Herrera wrote: > Andrew Dunstan wrote: > >> I already gave a use case that you dismissed in favour of a vague solution >> that we don't actually have. You seem to be the only person objecting to >> this proposal. > > I think that use case would be better served by a

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 9/7/15 7:21 PM, Andrew Dunstan wrote: > I already gave a use case that you dismissed in favour of a vague > solution that we don't actually have. But that's also the only use case so far, which seems a little thin. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 09/08/2015 04:21 PM, Peter Eisentraut wrote: On 9/7/15 7:32 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: I already gave a use case that you dismissed in favour of a vague solution that we don't actually have. You seem to be the only person objecting to this proposal. I think that use

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sun, Sep 6, 2015 at 3:34 PM, Joe Conway wrote: > On 09/02/2015 02:54 PM, Alvaro Herrera wrote: >> Josh Berkus wrote: >>> On 09/02/2015 02:34 PM, Alvaro Herrera wrote: I think trying to duplicate the exact strings isn't too nice an interface. >>> >>> Well, for

Re: [HACKERS] exposing pg_controldata and pg_config as functions

Andrew Dunstan wrote: > I already gave a use case that you dismissed in favour of a vague solution > that we don't actually have. You seem to be the only person objecting to > this proposal. I think that use case would be better served by a completely different interface -- some way to query the

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 09/06/2015 12:34 PM, Joe Conway wrote: > To the extent that we want specific pg_controldata output in non-text > form, we should identify which items those are and provide individual > functions for them. Well, I think it's pretty simple, let's take it down: # function

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 09/06/2015 11:17 PM, Peter Eisentraut wrote: On 9/6/15 3:34 PM, Joe Conway wrote: On 09/02/2015 02:54 PM, Alvaro Herrera wrote: Josh Berkus wrote: On 09/02/2015 02:34 PM, Alvaro Herrera wrote: I think trying to duplicate the exact strings isn't too nice an interface. Well, for

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 9/6/15 3:34 PM, Joe Conway wrote: > On 09/02/2015 02:54 PM, Alvaro Herrera wrote: >> Josh Berkus wrote: >>> On 09/02/2015 02:34 PM, Alvaro Herrera wrote: I think trying to duplicate the exact strings isn't too nice an interface. >>> >>> Well, for pg_controldata, no, but what else

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 09/02/2015 02:54 PM, Alvaro Herrera wrote: > Josh Berkus wrote: >> On 09/02/2015 02:34 PM, Alvaro Herrera wrote: >>> I think trying to duplicate the exact strings isn't too nice an >>> interface. >> >> Well, for pg_controldata, no, but what else would you do for pg_config? > > I was primarily

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Wed, Sep 2, 2015 at 5:31 PM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/02/2015 05:25 PM, Tom Lane wrote: >> Robert Haas writes: >>> But I'm not sure I like the idea of adding a server dependency on >>> the ability

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Mon, Aug 31, 2015 at 9:47 PM, Peter Eisentraut wrote: > On 8/25/15 11:32 PM, Joe Conway wrote: >> 1.) pg_controldata() function and pg_controldata view added > > I don't think dumping out whatever pg_controldata happens to print as a > bunch of text fields is very

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/02/2015 05:25 PM, Tom Lane wrote: > Robert Haas writes: >> But I'm not sure I like the idea of adding a server dependency on >> the ability to exec pg_controldata. That seems like it could be >> unreliable at best, and

Re: [HACKERS] exposing pg_controldata and pg_config as functions

Josh Berkus wrote: > On 09/02/2015 02:34 PM, Alvaro Herrera wrote: > > I think trying to duplicate the exact strings isn't too nice an > > interface. > > Well, for pg_controldata, no, but what else would you do for pg_config? I was primarily looking at pg_controldata, so we agree there. As for

Re: [HACKERS] exposing pg_controldata and pg_config as functions

Robert Haas writes: > But I'm not sure I like the idea of adding a server dependency on the > ability to exec pg_controldata. That seems like it could be > unreliable at best, and a security vulnerability at worst. I hadn't been paying attention --- the proposed patch

Re: [HACKERS] exposing pg_controldata and pg_config as functions

Tom Lane wrote: > Robert Haas writes: > > But I'm not sure I like the idea of adding a server dependency on the > > ability to exec pg_controldata. That seems like it could be > > unreliable at best, and a security vulnerability at worst. > > I hadn't been paying

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 09/02/2015 02:34 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> Robert Haas writes: >>> But I'm not sure I like the idea of adding a server dependency on the >>> ability to exec pg_controldata. That seems like it could be >>> unreliable at best, and a security

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 8/20/15 9:59 AM, Andrew Dunstan wrote: > The regression tests thus passed, but should not have. It occurred to me > that if we had a test like > > select pg_config('configure') ~ '--with-libxml' as has_xml; > > in the xml tests then this failure mode would be detected. This particular

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 8/24/15 9:50 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 08/23/2015 08:58 PM, Michael Paquier wrote: >>> I think that's a good thing to have, now I have concerns about making >>> this data readable for non-superusers. Cloud deployments of Postgres >>> are logically

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 8/25/15 11:32 PM, Joe Conway wrote: > 1.) pg_controldata() function and pg_controldata view added I don't think dumping out whatever pg_controldata happens to print as a bunch of text fields is very sophisticated. We have functionality to compute with WAL positions, for example, and they

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/2015 06:33 AM, Stephen Frost wrote: * Joe Conway (m...@joeconway.com) wrote: Issues needing comment: a.) Which items need hiding from non-superusers and should the value be redacted or the entire result set row be suppressed? I'm of

Re: [HACKERS] exposing pg_controldata and pg_config as functions

* Joe Conway (m...@joeconway.com) wrote: On 08/26/2015 06:33 AM, Stephen Frost wrote: * Joe Conway (m...@joeconway.com) wrote: Issues needing comment: a.) Which items need hiding from non-superusers and should the value be redacted or the entire result set row be suppressed? I'm of

Re: [HACKERS] exposing pg_controldata and pg_config as functions

* Joe Conway (m...@joeconway.com) wrote: Issues needing comment: a.) Which items need hiding from non-superusers and should the value be redacted or the entire result set row be suppressed? I'm of the opinion that we need to at least redact it and that what we should do is simply suppress

Re: [HACKERS] exposing pg_controldata and pg_config as functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2015 08:52 AM, Joe Conway wrote: On 08/24/2015 06:50 AM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: On 08/23/2015 08:58 PM, Michael Paquier wrote: I think that's a good thing to have, now I have concerns about making this

  1   2   >