Peter,
What is the status of this patch now? I read that two bugs has been
fixed in this patch and now it is waiting for new review. Is there
something what I can/must do?
Zdenek
Peter Eisentraut wrote:
Zdenek Kotala wrote:
OK. I split patch to two parts. Part one
Zdenek Kotala wrote:
Peter,
What is the status of this patch now? I read that two bugs has been
fixed in this patch and now it is waiting for new review. Is there
something what I can/must do?
The patch was applied, fixed, and fixed again, then reverted. It will
sit until just before
Am Mittwoch, 23. August 2006 14:44 schrieb Zdenek Kotala:
What is the status of this patch now? I read that two bugs has been
fixed in this patch and now it is waiting for new review. Is there
something what I can/must do?
As I said previously, if you are refactoring code to make it longer,
Peter Eisentraut wrote:
Am Mittwoch, 23. August 2006 14:44 schrieb Zdenek Kotala:
What is the status of this patch now? I read that two bugs has been
fixed in this patch and now it is waiting for new review. Is there
something what I can/must do?
As I said previously, if you are
Patch applied. Thanks.
---
Zdenek Kotala wrote:
Peter Eisentraut wrote:
The way I see it, combining a feature change with a code refactoring and
random white space changes is a pretty optimal way to get your
Peter Eisentraut napsal(a):
Zdenek Kotala wrote:
OK. I split patch to two parts. Part one is refactoring of
set_config_options function. Part two implements feature Allow
commenting of variables in postgresql.conf to restore them to
defaults.
I'm having trouble wrapping my head around a code
Zdenek Kotala wrote:
OK. I split patch to two parts. Part one is refactoring of
set_config_options function. Part two implements feature Allow
commenting of variables in postgresql.conf to restore them to
defaults.
I'm having trouble wrapping my head around a code refactoring which
actually
Peter Eisentraut wrote:
The way I see it, combining a feature change with a code refactoring and
random white space changes is a pretty optimal way to get your patch
rejected. Please submit patches for these items separately.
OK. I split patch to two parts. Part one is refactoring of
Zdenek Kotala wrote:
I performed some cleanup in my code as well. I reduced some
conditions, which cannot occur and fixed context validation in the
set_config_options function. I hope that It is final version of our
patch.
The way I see it, combining a feature change with a code refactoring
Joachim,
I checked your improvement and fix some problem with following scenario:
shared_buffers = 3301
START
share_buffers = 333.39
HUP
share_buffers requires integer value. Skip configuration file
#share_buffers = 3301
HUP
silent - no message
I performed some cleanup in my code as well.
Joachim Wieland wrote:
Zdenek,
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. That way, at every moment you can see if the
Zdenek,
On Fri, Jul 14, 2006 at 12:17:55AM +0200, Zdenek Kotala wrote:
There is last version of patch with following changes/improvements:
1) I divide set_config_option to more smaller functions without backside
effect.
I did not check the changes you have done to set_config_option and the
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
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
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
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
There is last version of patch with following changes/improvements:
1) I divide set_config_option to more smaller functions without backside
effect.
2) Behavior of reconfiguration is same in SIG_HUP context (exclude
elevel). All errors are reported and full validity of file is checked too.
Joachim Wieland wrote:
Still it does not what I think it should do. I might have been unclear
before. If you put a comment in front of a PGC_POSTMASTER variable (and if
its value differs from the default) then this should be treated as if the
variable got changed and it should emmit a warning
Zdenek Kotala [EMAIL PROTECTED] writes:
2) GUC_DISALLOW_IN_FILE flag is ignored during configuration file parsing.
Yeah, that's not enforced at the moment, it's just documentation.
Most of the variables that are marked that way have other defenses
against being changed from the file, so I'm not
Zdenek,
On Thu, Jun 01, 2006 at 04:56:10PM +0200, Zdenek Kotala wrote:
Thanks, You have right. It is problem with silent skip some option in
set_config_option function when PGC_SIGHUP is running context.
I fix it and I attach third version of patch.
Still it does not what I think it should
Thanks, You have right. It is problem with silent skip some option in
set_config_option function when PGC_SIGHUP is running context.
I fix it and I attach third version of patch.
Zdenek
Joachim Wieland wrote:
Zdenek,
On Wed, May 31, 2006 at 06:13:04PM +0200, Zdenek Kotala wrote:
There is second version of patch. I made following changes:
- fix problem with assertion
- use boot_val instead default_val for all configuration data types
- add GUC_JUST_RELOAD status to track what is in configuration file or not
- revert only commented out variables
- add message what is
Zdenek,
On Wed, May 31, 2006 at 06:13:04PM +0200, Zdenek Kotala wrote:
Joachim, could you explain me second point? I cannot determine
described problem. By my opinion my patch does not change this behavior.
I guess what I saw was another phenomenon:
I do the following:
- vi postgresql.conf
Zdenek,
On Wed, May 24, 2006 at 04:27:01PM +0200, Zdenek Kotala wrote:
General config structure is extend with default_val attribute to keep
really default value. (There is small conflict - for string boot_val
has same meaning).
During reconfiguration all values which has reset source equal
Joachim,
thanks for your comments. I am working on them.
Zdenek
Joachim Wieland wrote:
Zdenek,
Three points after a quick test:
- please compile with --enable-cassert, there are wrong assertions in your
code (you might just have to move some lines, there is an Assert() and an
Zdenek Kotala wrote:
There is path implements following item from todo list: Allow
commenting of variables in postgresql.conf to restore them to defaults.
Main idea is:
General config structure is extend with default_val attribute to keep
really default value. (There is small conflict - for
Andrew Dunstan wrote:
Zdenek Kotala wrote:
There is path implements following item from todo list: Allow
commenting of variables in postgresql.conf to restore them to defaults.
Main idea is:
General config structure is extend with default_val attribute to keep
really default value. (There is
Zdenek Kotala wrote:
Andrew Dunstan wrote:
Zdenek Kotala wrote:
There is path implements following item from todo list: Allow
commenting of variables in postgresql.conf to restore them to defaults.
Main idea is:
General config structure is extend with default_val attribute to keep
Alvaro Herrera wrote:
Zdenek Kotala wrote:
Zdenek Kotala wrote:
There is path implements following item from todo list: Allow
commenting of variables in postgresql.conf to restore them to defaults.
Main idea is:
General config structure is extend with default_val attribute to keep
29 matches
Mail list logo
