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(at)redhat(dot)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 Berkus
Aglio Database Solutions
San 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(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)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(at)agliodbs(dot)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(at)redhat(dot)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