Обсуждение: Custom gucs visibility
Hi,
So, if I have a contrib module which adds in a custom guc via DefineCustomIntVariable() for example. Now that custom guc is not visible via a show command unless that corresponding .so has been loaded into memory.
E.g.So, if I have a contrib module which adds in a custom guc via DefineCustomIntVariable() for example. Now that custom guc is not visible via a show command unless that corresponding .so has been loaded into memory.
postgres=# show pg_buffercache.fancy_custom_guc;
ERROR: unrecognized configuration parameter "pg_buffercache.fancy_custom_guc"
Should we do something about this or we are ok with the current behavior? I would prefer to get to see the config parameter value if I so happen to want to see it before the load of that contrib module. Thoughts?
Regards,
Nikhils
Regards,
Nikhils
On Tue, Jul 2, 2013 at 9:32 AM, Nikhil Sontakke <nikkhils@gmail.com> wrote: > So, if I have a contrib module which adds in a custom guc via > DefineCustomIntVariable() for example. Now that custom guc is not visible > via a show command unless that corresponding .so has been loaded into > memory. > > E.g. > > postgres=# show pg_buffercache.fancy_custom_guc; > ERROR: unrecognized configuration parameter > "pg_buffercache.fancy_custom_guc" > > Should we do something about this or we are ok with the current behavior? I > would prefer to get to see the config parameter value if I so happen to want > to see it before the load of that contrib module. Thoughts? If we haven't loaded the .so yet, where would we get the list of custom GUCs from? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 2, 2013 at 9:32 AM, Nikhil Sontakke <nikkhils@gmail.com> wrote:
>> Should we do something about this or we are ok with the current behavior? I
>> would prefer to get to see the config parameter value if I so happen to want
>> to see it before the load of that contrib module. Thoughts?
> If we haven't loaded the .so yet, where would we get the list of
> custom GUCs from?
This has come up before. We could show the string value of the GUC, if
it's been set in postgresql.conf, but we do not have correct values for
any of the other columns in pg_settings; nor are we even sure that the
module will think the value is valid once it does get loaded. So the
consensus has been that allowing the GUC to be printed would be more
misleading than helpful.
regards, tom lane
On Tue, Jul 02, 2013 at 11:37:13AM -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Tue, Jul 2, 2013 at 9:32 AM, Nikhil Sontakke <nikkhils@gmail.com> wrote: > >> Should we do something about this or we are ok with the current > >> behavior? I would prefer to get to see the config parameter value > >> if I so happen to want to see it before the load of that contrib > >> module. Thoughts? > > > If we haven't loaded the .so yet, where would we get the list of > > custom GUCs from? > > This has come up before. We could show the string value of the GUC, > if it's been set in postgresql.conf, but we do not have correct > values for any of the other columns in pg_settings; nor are we even > sure that the module will think the value is valid once it does get > loaded. So the consensus has been that allowing the GUC to be > printed would be more misleading than helpful. How about printing them with something along the lines of, "Please load extension foobar for details" or (less informative, but possibly easier to code) "libfoobar.so not loaded." ? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
How about printing them with something along the lines of, "Please> > If we haven't loaded the .so yet, where would we get the list of
> > custom GUCs from?
>
> This has come up before. We could show the string value of the GUC,
> if it's been set in postgresql.conf, but we do not have correct
> values for any of the other columns in pg_settings; nor are we even
> sure that the module will think the value is valid once it does get
> loaded. So the consensus has been that allowing the GUC to be
> printed would be more misleading than helpful.
load extension foobar for details" or (less informative, but possibly
easier to code) "libfoobar.so not loaded." ?
Well, we have done the "CREATE EXTENSION" successfully earlier. Also, the GUC becomes "automagically" visible after the backend has executed a function from that extension ( in which case the .so gets loaded as part of the function handling).
Also note that SET foo.custom_guc works ok by setting up a placeholder guc if the .so has not been loaded yet.
I wonder if we should dare to try to load the .so if a 'SHOW extension_name.custom_guc' is encountered via internal_load_library or something? Obviously we should check if the extension was created before as well.
Also note that SET foo.custom_guc works ok by setting up a placeholder guc if the .so has not been loaded yet.
I wonder if we should dare to try to load the .so if a 'SHOW extension_name.custom_guc' is encountered via internal_load_library or something? Obviously we should check if the extension was created before as well.
Regards,
Nikhils
Nikhils
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate