On 14/02/2023 03:42, Kyotaro Horiguchi wrote:
At Mon, 13 Feb 2023 12:18:07 +0900, Michael Paquier wrote
in
On Mon, Feb 13, 2023 at 11:27:58AM +0900, Kyotaro Horiguchi wrote:
I think currently the output by --describe-config can be used only for
consulting while editing a (possiblly broken)
At Mon, 13 Feb 2023 12:18:07 +0900, Michael Paquier wrote
in
> On Mon, Feb 13, 2023 at 11:27:58AM +0900, Kyotaro Horiguchi wrote:
> > I think currently the output by --describe-config can be used only for
> > consulting while editing a (possiblly broken) config file. Thus I
> > think it's no
On Mon, Feb 13, 2023 at 11:27:58AM +0900, Kyotaro Horiguchi wrote:
> I think currently the output by --describe-config can be used only for
> consulting while editing a (possiblly broken) config file. Thus I
> think it's no use showing GIC_DISALLOW_IN_FILE items there unless we
> use
At Fri, 10 Feb 2023 16:43:15 +0900, Michael Paquier wrote
in
> On Wed, Feb 08, 2023 at 09:42:13PM -0500, Tom Lane wrote:
> > Hm. On the one hand, if it is in fact not in postgresql.conf.sample,
> > then that flag should be set for sure. OTOH I see that that flag
> > isn't purely
On Wed, Feb 08, 2023 at 09:42:13PM -0500, Tom Lane wrote:
> Hm. On the one hand, if it is in fact not in postgresql.conf.sample,
> then that flag should be set for sure. OTOH I see that that flag
> isn't purely documentation: help_config.c thinks it should hide
> GUCs that are marked that way.
Justin Pryzby writes:
> On Thu, Feb 09, 2023 at 10:28:14AM +0900, Michael Paquier wrote:
>> I am wondering.. Did people notice that this adds GUC_NOT_IN_SAMPLE
>> to config_file in guc_tables.c? This makes sense in the long run
>> based on what this parameter is by design, still there may be an
On Thu, Feb 09, 2023 at 10:28:14AM +0900, Michael Paquier wrote:
> On Wed, Feb 08, 2023 at 04:21:57PM +0530, Nitin Jadhav wrote:
> > Makes sense and the patch looks good to me.
>
> Ah, OK. Thanks for the feedback!
>
> I am wondering.. Did people notice that this adds GUC_NOT_IN_SAMPLE
> to
On Wed, Feb 08, 2023 at 04:21:57PM +0530, Nitin Jadhav wrote:
> Makes sense and the patch looks good to me.
Ah, OK. Thanks for the feedback!
I am wondering.. Did people notice that this adds GUC_NOT_IN_SAMPLE
to config_file in guc_tables.c? This makes sense in the long run
based on what this
> Okay, the part to add an initialization check for GUC_NO_SHOW_ALL and
> GUC_NOT_IN_SAMPLE looked fine by me, so applied after more comment
> polishing.
>
> 0001 has been applied to clean up the existing situation.
Thanks for committing these 2 changes.
> On top of that, I have noticed an
On Mon, Feb 06, 2023 at 04:23:02PM +0900, Michael Paquier wrote:
> On top of that, I have noticed an extra combination that would not
> make sense and that could be checked with the SQL queries:
> GUC_DISALLOW_IN_FILE implies GUC_NOT_IN_SAMPLE. The opposite may not
> be true, though, as some
On Sun, Feb 05, 2023 at 12:56:58AM +0530, Nitin Jadhav wrote:
> Ok. Understood the other problems. I have attached the v2 patch which
> uses the idea present in Michael's patch. In addition, I have removed
> fetching NO_SHOW_ALL parameters while creating tab_settings_flags
> table in guc.sql and
> I don't particularly see why that needs to be the case. Notably,
> if we're interested in enforcing a policy even for extension GUCs,
> guc.sql can't really do that since who knows whether the extension's
> author will bother to run that test with the extension loaded.
> On the other hand,
Nitin Jadhav writes:
> My concern is if we do this, then we will end up having some policies
> (which can be read from pg_show_all_settings()) in guc.sql and some in
> guc.c. I feel all these should be at one place either at guc.c or
> guc.sql.
I don't particularly see why that needs to be the
> > Thanks Michael for identifying a new mistake. I am a little confused
> > here. I don't understand why GUC_NO_SHOW_ALL depends on other GUCs
> > like GUC_NOT_IN_SAMPLE or GUC_NO_RESET_ALL. Looks like the dependency
> > between GUC_NO_RESET_ALL and GUC_NO_SHOW_ALL is removed in the above
> >
On Wed, Feb 01, 2023 at 02:29:23PM +0900, Michael Paquier wrote:
> As also mentioned upthread by Tom, I am not sure that this combination
> makes much sense, actually, because I don't see why one would never
> want to know what is the effective value loaded for a parameter stored
> in a file when
On Mon, Jan 30, 2023 at 05:12:27PM +0530, Nitin Jadhav wrote:
> Thanks Michael for identifying a new mistake. I am a little confused
> here. I don't understand why GUC_NO_SHOW_ALL depends on other GUCs
> like GUC_NOT_IN_SAMPLE or GUC_NO_RESET_ALL. Looks like the dependency
> between
> I kind of think this is a lot of unnecessary work. The case that is
> problematic is a GUC that's marked GUC_NO_SHOW_ALL but not marked
> GUC_NOT_IN_SAMPLE. There aren't any of those, and I don't think there
> are likely to be any in future, because it doesn't make a lot of sense.
> Why don't
On Sun, Jan 29, 2023 at 01:05:07PM -0500, Tom Lane wrote:
> I kind of think this is a lot of unnecessary work. The case that is
> problematic is a GUC that's marked GUC_NO_SHOW_ALL but not marked
> GUC_NOT_IN_SAMPLE. There aren't any of those, and I don't think there
> are likely to be any in
Justin Pryzby writes:
> SELECT pg_show_all_settings() ought to keep working when called with no
> parameter. Tom gave me a hint how to do that for system catalogs here:
> https://www.postgresql.org/message-id/17988.1584472...@sss.pgh.pa.us
> In this case, it might be cleaner to add a second
On Sun, Jan 29, 2023 at 05:22:13PM +0530, Nitin Jadhav wrote:
> > We could extend pg_show_all_settings() with a boolean parameter to
> > enforce listing all the parameters, even the ones that are marked as
> > NOSHOW, but this does not count on GetConfigOptionValues() that could
> > force a
> We could extend pg_show_all_settings() with a boolean parameter to
> enforce listing all the parameters, even the ones that are marked as
> NOSHOW, but this does not count on GetConfigOptionValues() that could
> force a parameter to become noshow on a superuser-only GUC depending
> on the role
> We would miss the names of the parameters that are marked as NO_SHOW,
> missing from pg_settings, making debugging harder.
>
> This would make the test more costly by forcing one SQL for each
> GUC..
I agree.
> We could extend pg_show_all_settings() with a boolean parameter to
> enforce
On Sat, Jan 14, 2023 at 07:10:55PM +0530, Nitin Jadhav wrote:
> Option-1 is, expose a function like pg_settings_get_no_show_all()
> which just returns the parameters which are just listed as
> GUC_NO_SHOW_ALL (Not in combination with NOT_IN_SAMPLE). We can then
> use this function in the test file
> Looks like you're right ; show_all_settings() elides settings marked
> "noshow".
>
> Do you know how you'd implement a fix ?
I could think of the following options.
Option-1 is, expose a function like pg_settings_get_no_show_all()
which just returns the parameters which are just listed as
On Fri, Jan 13, 2023 at 06:15:38PM +0530, Nitin Jadhav wrote:
> Hi,
>
> The commit 7265dbffad7feac6ea9d373828583b5d3d152e07 has added a script
> in src/backend/utils/misc/check_guc that cross-checks the consistency
> of the GUCs with postgresql.conf.sample, making sure that its format
> is in
Hi,
The commit 7265dbffad7feac6ea9d373828583b5d3d152e07 has added a script
in src/backend/utils/misc/check_guc that cross-checks the consistency
of the GUCs with postgresql.conf.sample, making sure that its format
is in line with what guc.c has. As per the commit message, the
parameters which are
26 matches
Mail list logo
