Re: Advice regarding configuration parameters - Mailing list pgsql-hackers
From | James William Pye |
---|---|
Subject | Re: Advice regarding configuration parameters |
Date | |
Msg-id | 20040210220314.GK476@void.ph.cox.net Whole thread Raw |
In response to | Re: Advice regarding configuration parameters (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On 02/06/04:05/5, Tom Lane wrote: > To: Joe Conway <mail@joeconway.com> > Cc: Peter Eisentraut <peter_e@gmx.net>, > Thomas Hallgren <thhal@mailblocks.com>, > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Advice regarding configuration parameters > Date: Fri, 06 Feb 2004 13:15:02 -0500 > Message-ID: <4515.1076091302@sss.pgh.pa.us> > From: Tom Lane <tgl@sss.pgh.pa.us> > > Joe Conway <mail@joeconway.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
pgsql-hackers by date: