Thread: BUG #1466: #maintenace_work_mem = 16384
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.
> 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
"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
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
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 > > > >
> > 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
"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
> > 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
"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