Обсуждение: Re: [PATCHES] Allow commenting of variables in postgresql.conf to - try 4
Joachim Wieland <joe@mcknight.de> 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
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Joachim Wieland <joe@mcknight.de> 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
Вложения
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/
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
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
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/