Thread: pg_guc
Hi Peter, We have a server side GUI utility that among other things let us configure GUC variables. We badly need to know what variables exist in the specific backend version, which are the min and max values and if possible a description. The option is to hardwire these things into the code which is very awkward (and we want it to work with different backend versions, backends compiled differently etc.). As there are some very useful utilities that we already use (besides pg_ctl) like pg_config and pg_controldata, we thought of having a pg_guc one so that we could call it in the same bin directory as the postmaster to obtain info about that postmaster's defined GUC variables. Note that this is a configuration utility, so we don't have, in most instances, a database to connect to (as we haven't even initialized PGDATA in most cases). Aizaz have, with hints from Tom Lane, implemented a basic version of such utility. We thought that this can be used by other tools as well, so it would be nice to have it added to the 7.4 release. Possible future extensions to this program, which already has knowledge about GUC variables, would be adding the capability of changing variable values in an specific postgresql.conf file (by specifying -D perhaps) or even generating a sample postgresql.conf file (this will ensure it always match the latest code). Anyway, I hope you find this useful and people find the motivation to enhance it. Aizaz is already working on the internationalization. Best regards, Fernando -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9
Fernando, > We have a server side GUI utility that among other things let us configure GUC > variables. We badly need to know what variables exist in the specific backend > version, which are the min and max values and if possible a description. The > option is to hardwire these things into the code which is very awkward (and we > want it to work with different backend versions, backends compiled differently > etc.). As the new "GUC List" guru, I will send you a list in PDF or SXW format which covers 7.3 and 7.4 this weekend. If you database it, I would love to have the table back in return. Please note that the actual maximum value for many variables is much larger than the practical maximum value. For example, RANDOM_PAGE_COST is only limited to INT MAX on the host OS, even though all practical values are between 1 and 10. -- -Josh BerkusAglio Database SolutionsSan Francisco
Fernando Nasser writes: > We have a server side GUI utility that among other things let us configure GUC > variables. We badly need to know what variables exist in the specific backend > version, which are the min and max values and if possible a description. In that case I think it's best to put it directly into the server executable and add an option like --help-long or possibly some variations if you need specific program-parsable formats. This would certainly solve a few of the implementation concerns I've heard about, and it's also a fairly logical place to look for it. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Fernando Nasser writes:
>> We have a server side GUI utility that among other things let us configure GUC
>> variables. We badly need to know what variables exist in the specific backend
>> version, which are the min and max values and if possible a description.
> In that case I think it's best to put it directly into the server
> executable and add an option like --help-long or possibly some variations
> if you need specific program-parsable formats. This would certainly solve
> a few of the implementation concerns I've heard about, and it's also a
> fairly logical place to look for it.
Hm. We had toyed with that idea for a bit but rejected it on the
grounds that it would add bloat to the postgres executable. On the
other hand, two sets of message catalogs would bloat an installation
even more. Maybe that's the best plan after all.
Aizaz, if you look at backend/main/main.c it should be pretty obvious
how to handle this --- it's just like bootstrap mode. main.c kicks off
control to GucInfoMain or whatever we call it, and then that routine
can act pretty much the same as if it were the actual main() of a
standalone pg_guc. This also eliminates the need for VARADDR() and a
lot of the other thrashing about we were doing to allow creation of
a standalone variable table ... in fact, I think quite a large
percentage of the patch disappears ...
regards, tom lane
Tom, > Aizaz, if you look at backend/main/main.c it should be pretty obvious > how to handle this --- it's just like bootstrap mode. main.c kicks off > control to GucInfoMain or whatever we call it, and then that routine > can act pretty much the same as if it were the actual main() of a > standalone pg_guc. This also eliminates the need for VARADDR() and a > lot of the other thrashing about we were doing to allow creation of > a standalone variable table ... in fact, I think quite a large > percentage of the patch disappears ... Are you suggesting putting a copy of the list of GUCs in a system table? I'd be for that .... -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> Are you suggesting putting a copy of the list of GUCs in a system
> table?
Aizaz is not doing that, but see Joe Conway's proposed patch to
pg_settings.
regards, tom lane
On Fri, 2003-06-27 at 11:52, Josh Berkus wrote: > Are you suggesting putting a copy of the list of GUCs in a system table? I'd > be for that .... hmmm ... I thought what this meant was that we don't factor the tables out into guc_vars.h, but leave them in guc.c. (adding the descriptions etc. there). In 'bootstrap' mode, main.c can output the values without ever connecting to the database ... Thanks, Aizaz
Aizaz Ahmed <aahmed@redhat.com> writes:
> On Fri, 2003-06-27 at 11:52, Josh Berkus wrote:
>> Are you suggesting putting a copy of the list of GUCs in a system table? I'd
>> be for that ....
> hmmm ... I thought what this meant was that we don't factor the tables
> out into guc_vars.h, but leave them in guc.c. (adding the descriptions
> etc. there). In 'bootstrap' mode, main.c can output the values without
> ever connecting to the database ...
Right. There is a separate proposal on the table to make more of the
guc.c tabular information visible in the pg_settings view, so that
clients of a running database can get at it. That's independent of what
you're doing though. See pgsql-patches a day or two back, and
discussion a little before that on (I think) pgsql-general.
regards, tom lane
On Fri, 2003-06-27 at 10:32, Tom Lane wrote: > Aizaz, if you look at backend/main/main.c it should be pretty obvious > how to handle this --- it's just like bootstrap mode. main.c kicks off > control to GucInfoMain or whatever we call it, and then that routine > can act pretty much the same as if it were the actual main() of a > standalone pg_guc. This also eliminates the need for VARADDR() and a > lot of the other thrashing about we were doing to allow creation of > a standalone variable table ... in fact, I think quite a large > percentage of the patch disappears ... So I guess that means pg_guc should be put back in /src/backend/utils/misc ? or is there some other directory it should be placed in now? What about the DESC_DETAIL macro that was used to compile a short vs long description? Is the backend going to have the long description compiled right into it? Will there be only one description, short or long? (if short we can use it in SHOW, (perhaps)) or should I create an extra field in the GUC tables for a separate long field. (you were quite opposed to this)? If pg_guc is going to get built with the rest of the backend, I could avoid that code refactoring from xlog.c that I did.(the fsync flags and the creation of the syncflag.h file). Should I include these changes to the patch anyway? and ... will you be around perhaps on Sunday to answer any questions that may come up? Thanks, Aizaz