Re: Advice regarding configuration parameters

On 02/06/04:05/5, Tom Lane wrote:
> To: Joe Conway <mail(at)joeconway(dot)com>
> Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>,
> Thomas Hallgren <thhal(at)mailblocks(dot)com>,
> pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Advice regarding configuration parameters
> Date: Fri, 06 Feb 2004 13:15:02 -0500
> Message-ID: <4515(dot)1076091302(at)sss(dot)pgh(dot)pa(dot)us>
> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>
> Joe Conway <mail(at)joeconway(dot)com> writes:
> > I like it. I wonder if we ought to have a way to "register" valid
> > classes? Maybe a new guc variable in the form of a list of valid
> > classes. So something like:
>
> There are some order-of-processing issues there, but maybe. Another
> possibility is that after a shlib has finished registering its
> variables, it could look for remaining placeholders matching its prefix
> and issue WARNINGs about 'em (it can't realistically ERROR, probably,
> but a WARNING would surely help). These are actually orthogonal checks
> since one addresses the class part and the other the individual variable.
>
> >> And we'd have to think a little about how to handle variable values
> >> that are discovered to be erroneous when we try to assign them to the
> >> variable --- probably we can just drop them, but does that make the
> >> semantics weird at all?
>
> > Maybe we can require a default value as a parameter to
> > add_guc_variable() and use that?
>
> Well, the new GUC variable struct would include a default by definition,
> and presumably that value would "bubble up" to replace any values that
> are found illegal.
>
> The sort of semantic funny I am thinking of is like this:
> * postgresql.conf contains pljava::var = somegoodvalue
> * ALTER DATABASE SET supplies pljava::var = somebadvalue
> For builtin variables the ALTER DATABASE value would be rejected on
> sight and the end result would be that the variable contains
> 'somegoodvalue'. However if we don't yet know the variable at backend
> startup, 'somebadvalue' will replace 'somegoodvalue' completely, and
> then when the PL actually gets loaded it will get thrown away. End
> result is that the variable will have whatever its hardwired default is,
> and not 'somegoodvalue' as one would wish. Even more surprising, a
> subsequent SIGHUP would make it acquire 'somegoodvalue'.
>
> This particular case could be dealt with by forcing a rescan of
> postgresql.conf after new variables are defined (I think we need only do
> so if any errors are detected in assigning values), but that will not
> handle everything. We don't have any way to get back overridden values
> from other sources such as the postmaster command line.
>
> It seems likely to me that such corner cases are sufficiently bizarre to
> not bother anyone, but we need to think more to make sure that there
> aren't any that would bother someone.

What about having a designated GUC configuration file directory, one file per
class? When a given class is initialized, it tries to find its corresponding
config file in $DATA/conf/$CLASSFILENAME. $CLASSFILENAME then being able
to differ from the actual classname, perhaps. Also, the variable's classname
would be implied from the filename that it's loaded from. So no need to
"class<some specifier>varname".

I guess postgres.conf should be considered the 'main' or 'postgres' class,
and should probably exist in $DATA/conf/(postgres|main), or whatever people
think is the most descriptive. It doesn't have to be moved, but I figure it
would take away one special case(except on setting a var without classname).

I think this would resolve any out of order issues with one file. No?

Regards,
James William Pye