Re: [Util] Warn and Remove Invalid GUCs

From: Shaik Mohammad Mujeeb <mujeeb(dot)sk(at)zohocorp(dot)com>
To: "htamfids" <htamfids(at)gmail(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Srinath Reddy Sadipiralla" <srinath2133(at)gmail(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, "mujeebskdev" <mujeeb(dot)sk(dot)dev(at)gmail(dot)com>
Subject: Re: [Util] Warn and Remove Invalid GUCs
Date: 2025-05-23 14:01:06
Message-ID: 196fd729273.3f87a6b036577.1325760241006917620@zohocorp.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Greg,

> Well, we do have ways to view all *potential* extensions. I find myself more sympathetic to the OP than the others here, as I think it's a good idea to display a warning for a potentially misspelled GUC prefix (but do nothing else - certainly not remove it!). 

I'm really glad that you understood the problem statement clearly - thank you for the positive response.

> Will such a warning be seen? Perhaps not, but that's a risk any warning message has to face. And obviously there could be false positives if an extension decides to name their GUCs something other than pg_available_extensions()->name but hopefully that's a rare case (and shame on them if so.)

I do agree that such warnings might sometimes go unnoticed in the logs. However, by configuring specific log-related GUCs, it's possible to surface Postmaster warnings directly on the terminal during a PostgreSQL restart, rather than just logging them to a file. We've been using this setup in our production environments, and it's proven helpful in identifying typos right at server startup.

For example,

~ pgrestart

waiting for server to shut down.... done

server stopped

waiting for server to start....2025-05-23 13:48:20 GMT::@:[29146]:WARNING:  invalid configuration parameter name "pg_stut_statements.max"

2025-05-23 13:48:20 GMT::@:[29146]:DETAIL:  "pg_stut_statements.max" doesn't has a reserved prefix.

2025-05-23 13:48:21 GMT::@:[29146]:LOG:  redirecting log output to logging collector process

2025-05-23 13:48:21 GMT::@:[29146]:HINT:  Future log output will appear in directory "pg_log".

done

server started

So I felt this approach might be beneficial to others as well.

Regards,
Shaik Mohammad Mujeeb
Member Technical Staff
Zoho Corp

---- On Fri, 23 May 2025 01:49:53 +0530 Greg Sabino Mullane <htamfids(at)gmail(dot)com> wrote ---

On Thu, May 22, 2025 at 12:45 PM Tom Lane <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "lpgsql.bogus = 1" .

[ shrug... ] How do you know that's a bogus prefix?  It could perfectly well be a fully valid setting for an extension that
the installation doesn't choose to preload.

Well, we do have ways to view all *potential* extensions. I find myself more sympathetic to the OP than the others here, as I think it's a good idea to display a warning for a potentially misspelled GUC prefix (but do nothing else - certainly not remove it!). Will such a warning be seen? Perhaps not, but that's a risk any warning message has to face. And obviously there could be false positives if an extension decides to name their GUCs something other than pg_available_extensions()->name but hopefully that's a rare case (and shame on them if so.)

Cheers,

Greg

--

Crunchy Data - https://www.crunchydata.com

Enterprise Postgres Software Products & Tech Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2025-05-23 14:01:13 Re: PG 18 release notes draft committed
Previous Message Robert Haas 2025-05-23 13:56:11 Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part