Re: [Util] Warn and Remove Invalid GUCs
От | Shaik Mohammad Mujeeb |
---|---|
Тема | Re: [Util] Warn and Remove Invalid GUCs |
Дата | |
Msg-id | 196fd729273.3f87a6b036577.1325760241006917620@zohocorp.com обсуждение исходный текст |
Ответ на | Re: [Util] Warn and Remove Invalid GUCs (Greg Sabino Mullane <htamfids@gmail.com>) |
Список | 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!).
> 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,
So I felt this approach might be beneficial to others as well.
Regards,
Shaik Mohammad Mujeeb
Member Technical Staff
Zoho Corp
> 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@gmail.com> wrote ---
On Thu, May 22, 2025 at 12:45 PM Tom Lane <tgl@sss.pgh.pa.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.comEnterprise Postgres Software Products & Tech Support
В списке pgsql-hackers по дате отправления: