Re: [HACKERS] [PATCHES] Allow commenting of variables in postgresql.conf to - try 4
Joachim Wieland wrote: > On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote: > > Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost: > > > #2: That variable can *not* be changed by a reload. > > > Notice-level message is sent to the log notifying the admin > > > that the change requested could not be performed. > > > > This already happens. > > Not if the option gets commented/deleted, i.e.: > > shared_buffers = 8000 > START > #shared_buffers = 8000 > HUP > > This does not issue a message at the moment. Because at the moment, the above does not change the value of shared_buffers. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Allow commenting of variables in postgresql.conf to - try 4
On Mon, Jul 24, 2006 at 10:55:47AM -0400, Stephen Frost wrote: > #2: That variable can *not* be changed by a reload. > Notice-level message is sent to the log notifying the admin that the > change requested could not be performed. This change could be > either a revert to reset-value if it was removed/commented-out or an > explicit change request to a different value. Right. And what I am voting for is to not only issue such a message once but every time a SIGHUP is received as long as the actively-used value differs from the value in the configuration file. One of the reasons for having this fall-back-to-default-value stuff is to make sure that an admin can restart a server and be sure that it will behave in the same way as when it was shut down. Moreover it's just clearer to send the notice message every time a SIGHUP is received since every reload is the admin's request to apply all of the values in the configuration file independently of what has happened in the past. Joachim ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Allow commenting of variables in postgresql.conf to - try 4
On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote: > Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost: > > #2: That variable can *not* be changed by a reload. > > Notice-level message is sent to the log notifying the admin that the > > change requested could not be performed. > This already happens. Not if the option gets commented/deleted, i.e.: shared_buffers = 8000 START #shared_buffers = 8000 HUP This does not issue a message at the moment. Joachim ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Allow commenting of variables in postgresql.conf to - try 4
Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost: > #2: That variable can *not* be changed by a reload. > Notice-level message is sent to the log notifying the admin that the > change requested could not be performed. This already happens. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Allow commenting of variables in postgresql.conf to - try 4
* Tom Lane ([EMAIL PROTECTED]) wrote: > Joachim Wieland <[EMAIL PROTECTED]> writes: > > I did not check the changes you have done to set_config_option and the like > > but tested the commenting / uncommenting / changing of guc variables and the > > behavior and log output. The general idea (at least my idea) is that > > whenever a SIGHUP is received and there is some difference between the > > config file and the active value that the server is using, a notice message > > is written to the log. > > Notice message? Where did that come from? The behavior I thought > people were after was just that variables previously defined by the file > would revert to reset values if not any longer defined by the file. There's two issues here, I believe. There's the 'revert-to-reset-values' issue for things which can be changed with a reload and then there's also the 'notice-message-if-unable-to-change' a given variable without a reset. On reload a variable is changed: #1: That variable can be changed by a reload. If the variable has been removed/commented-out then it is reverted to the reset-value. Otherwise, the new value is used. #2: That variable can *not* be changed by a reload. Notice-level message is sent to the log notifying the admin that the change requested could not be performed. This change could be either a revert to reset-value if it was removed/commented-out or an explicit change request to a different value. Personally, I'm very interested in having both. I'm about 90% sure both were discussed previously on hackers and that the general consensus was that both were good. It's possible the second point wasn't noticed by everyone involved though. Of course, I might be misunderstanding what Joachim was referring to also. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] Allow commenting of variables in postgresql.conf to - try 4
Joachim Wieland <[EMAIL PROTECTED]> writes: > I did not check the changes you have done to set_config_option and the like > but tested the commenting / uncommenting / changing of guc variables and the > behavior and log output. The general idea (at least my idea) is that > whenever a SIGHUP is received and there is some difference between the > config file and the active value that the server is using, a notice message > is written to the log. Notice message? Where did that come from? The behavior I thought people were after was just that variables previously defined by the file would revert to reset values if not any longer defined by the file. >From a reviewer's point of view, it'd be nice if the patch did not contain so many useless changes of whitespace. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings