Thanks for the reply,
Been reading hackers of Aug 2004 and found the threads. It's a common habit to create two lines on the configuration
files,in order to maintain the copy of the default conf file. I guess this should be the worst scenery for a freshly
incomingDBA trying to put things in order.
A temporary patch, will be updating documentation, encouraging administrators to use the SHOW ALL; command in the
psqlenv, to confirm that changes where made.
In my case, a 1.2 gig file was written, performance was on the floor. And my previous situation, a reindex force task
lastsaturday, confused me. This is not a trivial problem, but in conjunction with other small problems could become a
bigone.
Good habits when touching conf files & using the SHOW ALL to confirm that changes where made will help until this is
patched.
Thanks for Postgres,
Regards, Guido.
> This issue was resently discussed on hackers. It is a known issue, not very
> convinient for the user. Nevertheless it is not fixed in 8.0, but will
> perhaps be addressed in the next major release.
> (Remembering, it was a non-trivial thing to change.)
>
> Best Regards,
> Michael Paesold
>
> G u i d o B a r o s i o wrote:
>
> > The solution appeared as something I didn't know
> >
> > On the .conf file
> >
> > Previous situation:
> >
> > #log_something=false
> > log_something=true
> >
> > Worst situation
> > #log_something=false
> > #log_something=true
> >
> > Nice situation
> > log_something=false
> > #log_something=true
> >
> >
> > Ok, the problem was that I assumed that commenting a value on
> > the conf file will set it up to a default (false?). I was wrong.
> > My server was writting tons of log's.
> >
> > Is this the normal behavior for pg_ctl reload? It seems that looks for new
> values, remembering the last state on the ones that actually are commented.
> Although it's my fault to have 2 (tow) lines for the same issue, and that I
> should realize that this is MY MISTAKE, the log defaults on a reload, if
> commented, tend to be the last value entered?
>