Thread: BUG #1466: #maintenace_work_mem = 16384

BUG #1466: #maintenace_work_mem = 16384

From
"Joe Brown"
Date:
The following bug has been logged online:

Bug reference:      1466
Logged by:          Joe Brown
Email address:      joebrown@rclooke.com
PostgreSQL version: 8.0.0.0
Operating system:   Windows XP
Description:        #maintenace_work_mem = 16384
Details:

I was attempting to reduce the already tiny memory footprint of postgres on
win32

I uncommented the a number of postgresql.conf parameters.

Uncommenting
maintenace_work_mem = 16384
caused the server immediately stop after start.
No errors reported, no logs generated.

Re: BUG #1466: #maintenace_work_mem = 16384

From
"Magnus Hagander"
Date:
> The following bug has been logged online:
>=20
> Bug reference:      1466
> Logged by:          Joe Brown
> Email address:      joebrown@rclooke.com
> PostgreSQL version: 8.0.0.0
> Operating system:   Windows XP
> Description:        #maintenace_work_mem =3D 16384
> Details:=20
>=20
> I was attempting to reduce the already tiny memory footprint=20
> of postgres on
> win32
>=20
> I uncommented the a number of postgresql.conf parameters.
>=20
> Uncommenting
> maintenace_work_mem =3D 16384
> caused the server immediately stop after start.
> No errors reported, no logs generated.

Did you check both eventlog and the pg_log directory? If so, try setting
the log_destibation parameter to log to eventlog only, in case there is
a problem starting the logger process, and see if you get something in
the eventlog then.

//Magnus

Re: BUG #1466: #maintenace_work_mem = 16384

From
Tom Lane
Date:
"Joe Brown" <joebrown@rclooke.com> writes:
> Uncommenting
> maintenace_work_mem = 16384
> caused the server immediately stop after start.

You apparently managed to change the spelling while uncommenting;
the actual line in the sample file is

#maintenance_work_mem = 16384       # min 1024, size in KB
         ^

> No errors reported, no logs generated.

The error is reported.  For instance, when I try this I get
$ postmaster
FATAL:  unrecognized configuration parameter "maintenace_work_mem"
$

            regards, tom lane

Re: BUG #1466: #maintenace_work_mem = 16384

From
Tom Lane
Date:
Joe Brown <joebrown@rclooke.com> writes:
> I checked all logs I could think of (event and pg_logs) and found no
> information.  I suppose if I tried starting postmaster by hand I would
> have spotted the issue.

Hmm.  I see at least part of the problem: the poweron default for
log_destination is "stderr" which is not very helpful on Windows;
the message is probably going to the bit bucket since any destination
change you may have requested in postgresql.conf probably hasn't been
applied yet.  (Joe, if you put log_destination = eventlog in the conf
file before the mistaken entry, does it report properly?)

Seems like we need a different poweron default on Windows.

            regards, tom lane

Re: BUG #1466: #maintenace_work_mem = 16384

From
Joe Brown
Date:
w/egg on face, DOH

I did try to make sure I didn't submit a bogus report, but didn't try
hard enough.

I checked all logs I could think of (event and pg_logs) and found no
information.  I suppose if I tried starting postmaster by hand I would
have spotted the issue.

This didn't help me diagnose the issue:
runas /user:postgres "p:\PostgreSQL\8.0\bin\pg_ctl.exe start -D
p:\PostgreSQL\8.0\data"

Ok, now I ask for the world...  Can we force postgres to log startup
failure?  I figured that was what was going on, but I didn't think to
login as postgres and start it by hand to see the output.

Tom Lane wrote:

>"Joe Brown" <joebrown@rclooke.com> writes:
>
>
>>Uncommenting
>>maintenace_work_mem = 16384
>>caused the server immediately stop after start.
>>
>>
>
>You apparently managed to change the spelling while uncommenting;
>the actual line in the sample file is
>
>#maintenance_work_mem = 16384       # min 1024, size in KB
>         ^
>
>
>
>>No errors reported, no logs generated.
>>
>>
>
>The error is reported.  For instance, when I try this I get
>$ postmaster
>FATAL:  unrecognized configuration parameter "maintenace_work_mem"
>$
>
>            regards, tom lane
>
>
>
>

Re: BUG #1466: #maintenace_work_mem = 16384

From
"Magnus Hagander"
Date:
> > I checked all logs I could think of (event and pg_logs) and=20
> found no=20
> > information.  I suppose if I tried starting postmaster by=20
> hand I would=20
> > have spotted the issue.
>=20
> Hmm.  I see at least part of the problem: the poweron default=20
> for log_destination is "stderr" which is not very helpful on=20
> Windows; the message is probably going to the bit bucket=20
> since any destination change you may have requested in=20
> postgresql.conf probably hasn't been applied yet.  (Joe, if=20
> you put log_destination =3D eventlog in the conf file before=20
> the mistaken entry, does it report properly?)
>=20
> Seems like we need a different poweron default on Windows.

There is code in there that's supposed to handle it, it just seems not
to work :-( See:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/error
/elog.c?rev=3D1.155

function write_stderr(). Probably it's not picking up that's it's
running as a service, which it really should. I remember testing this
when it went in, but probably haven't tested it lately. But I see no
changes in that.

Hmm. Looking at it, the fprintf(stderr, "%s", buf.data) in
send_message_to_server_log should probably be a write_stderr, shouldn't
it? Or will that break the redirect_stderr stuff?

On another note, is it really good for guc to be calling ereport()
before it has loaded the config options for ereport, or are there
possibly other areas that may be wrong as well?

//Magnus

Re: BUG #1466: #maintenace_work_mem = 16384

From
Tom Lane
Date:
"Magnus Hagander" <mha@sollentuna.net> writes:
> On another note, is it really good for guc to be calling ereport()
> before it has loaded the config options for ereport,

We don't have much choice.  This is why the power-up defaults have to be
at least somewhat sane for the platform.

            regards, tom lane

Re: BUG #1466: #maintenace_work_mem = 16384

From
"Magnus Hagander"
Date:
> > On another note, is it really good for guc to be calling ereport()=20
> > before it has loaded the config options for ereport,
>=20
> We don't have much choice.  This is why the power-up defaults=20
> have to be at least somewhat sane for the platform.

It could use write_stderr() if it fails the first time it loads the
config file, perhaps? But that may be far from a nice solution,
certainly.

The problem with changing the default from stderr to eventlog is that it
will send the messages to the eventlog even if running from the console,
which is not good.

Can defaults be set to the result of a function? If so we could use the
service checking function to change the default value,perhaps?

//Magnus

Re: BUG #1466: #maintenace_work_mem = 16384

From
Tom Lane
Date:
"Magnus Hagander" <mha@sollentuna.net> writes:
> Can defaults be set to the result of a function?

By "power-on default" I mean the value that the variable is assigned as
its static initializer.  That has to be a link-time constant (at least
in C ...).  Anything else will mean misbehavior if an error occurs
before the GUC code itself has been able to initialize.

> The problem with changing the default from stderr to eventlog is that it
> will send the messages to the eventlog even if running from the console,
> which is not good.

It's not perfect maybe, but it's certainly less bad than the present
behavior.  At least we know that the eventlog will always exist on
Windows.  I'm not sure how interesting the running-from-the-console
case actually is for Windows users anyway.

            regards, tom lane