Re: How about a psql backslash command to show GUCs?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Christoph Berg <myon@debian.org>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
Robert Haas <robertmhaas@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>,
Julien Rouhaud <rjuju123@gmail.com>,
Pavel Stehule <pavel.stehule@gmail.com>,
"David G. Johnston" <david.g.johnston@gmail.com>,
Joe Conway <mail@joeconway.com>,
Mark Dilger <mark.dilger@enterprisedb.com>,
Andrew Dunstan <andrew@dunslane.net>,
David Rowley <dgrowleyml@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-06-07T17:02:23Z
Lists: pgsql-hackers
Attachments
- use-PGC_S_DYNAMIC_DEFAULT-in-more-places-1.patch (text/x-diff) patch
Christoph Berg <myon@debian.org> writes: > in_hot_standby sounds very useful to have in that list. I thought about this some more and concluded that we're blaming the messenger. There's nothing wrong with \dconfig's filtering rule; rather, it's the fault of the backend for mislabeling a lot of run-time-computed values as source=PGC_S_OVERRIDE when they really are dynamic defaults. Now in fairness, I think a lot of that code predates the invention of PGC_S_DYNAMIC_DEFAULT, so there was not a better way when it was written ... but there is now. The attached draft patch makes the following changes: * All run-time calculations of PGC_INTERNAL variables are relabeled as PGC_S_DYNAMIC_DEFAULT. There is not any higher source value that we'd allow to set such a variable, so this is sufficient. (I didn't do anything about in_hot_standby, which is set through a hack rather than via set_config_option; not sure whether we want to do anything there, or what it should be if we do.) The net effect of this compared to upthread examples is to hide shared_memory_size and shared_memory_size_in_huge_pages from \dconfig. * The auto-tune value of wal_buffers is relabeled as PGC_S_DYNAMIC_DEFAULT if possible (but due to pre-existing hacks, we might have to force it). This will hide that one too as long as you didn't manually set it. * The rlimit-derived value of max_stack_depth is likewise relabeled as PGC_S_DYNAMIC_DEFAULT, resolving the complaint Jonathan had upthread. But now that we have a way to hide this, I'm having second thoughts about whether we should. If you are on a platform that's forcing an unreasonably small stack size, it'd be good if \dconfig told you so. Could it be sane to label that value as PGC_S_DYNAMIC_DEFAULT only when it's the limit value (2MB) and PGC_S_ENV_VAR when it's smaller? In any case, I expect that we'd apply this patch only to HEAD, which means that when using psql's \dconfig against a pre-v15 server, you'd still see these settings that we're trying to hide. That doesn't bother me too much, but maybe some would find it confusing. Thoughts? regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Be more careful about GucSource for internally-driven GUC settings.
- 7ab5b4eb4834 15.0 landed
-
Fix case sensitivity in psql's tab completion for GUC names.
- b5607b0746f4 15.0 landed
-
Further tweak the default behavior of psql's \dconfig.
- 139d46ee26a2 15.0 landed
-
Tweak the default behavior of psql's \dconfig.
- 5e70d8b5d18b 15.0 landed
-
psql: add \dconfig command to show server's configuration parameters.
- 3e707fbb4009 15.0 landed
-
Allow granting SET and ALTER SYSTEM privileges on GUC parameters.
- a0ffa885e478 15.0 cited