From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050524 Firefox/1.0 (Ubuntu package 1.0.2 MFSA2005-44)
Description of problem:
Migrating a database from a RHEL3 server to RHEL4; the previous postgresql.conf file had the options:
max_fsm_relations = 10000
max_fsm_pages = 100000
I copied this configuration to the new server and restarted postgres, which failed. The only message was [FAILED] at the end of the line. No other messages appeared on the console, no errors were logged to /var/log/pgsql, no errors were logged to /var/log/messages, except for this one:
Jun 3 17:53:05 keel postgresql: Starting postgresql service: failed
I ran "sh -x /etc/init.d/postgresql start", which gave no further information, but then tried the command that was being executed:
runuser -l postgres -c '/usr/bin/postmaster -p 5432 -D '\''/var/lib/pgsql/data'\'' &'
which finally reported:
FATAL: max_fsm_pages must exceed max_fsm_relations * 16
which, despite being weirdly incorrect, at least explains why postgresql isn't starting.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Cause a configuration error in data/postgresql.conf
2. Restart postgresql service.
Actual Results: Observed no error messages explaining the cause of the service failure.
Expected Results: FATAL errors should get logged to syslog and console, all other errors should at least make it to syslog.
(In reply to comment #0)
> max_fsm_relations = 10000
> max_fsm_pages = 100000
> FATAL: max_fsm_pages must exceed max_fsm_relations * 16
> which, despite being weirdly incorrect, at least explains why postgresql isn't
(ok, not weird at all, but the actual error is irrelevant here; only that it was
masked by the initscript)
Yeah, this is sort of a catch-22 situation. You can't really expect config-file
errors to get reported to syslog, since it's only after reading the config file
that the postmaster can know how to send stuff to syslog properly. The error is
in fact reported to postmaster's stderr, and the problem is that the default
setup in the initscript is to send stderr to /dev/null. Unfortunately we cannot
readily change that default either, because due to the lack of any log-rotation
capability in Postgres 7.*, any file we did send it to would grow without bound.
This is fixed in Postgres 8.0, and our packaging of 8.0 does do something more
intelligent with the default logging setup, but with 7.* there are no good
See also bug #103767
(In reply to comment #2)
> The error is
> in fact reported to postmaster's stderr, and the problem is that the default
> setup in the initscript is to send stderr to /dev/null. Unfortunately we cannot
> readily change that default either, because due to the lack of any log-rotation
> capability in Postgres 7.*, any file we did send it to would grow without bound.
Well, what about leaving it going to stderr, so that the operator running the
initscript can see the FATAL messages, instead of redirecting it to /dev/null or
As long as the FATALs aren't masked, it doesn't matter where they go -- I don't
want to jump through hoops to find out an error that postgres is trying to tell me.
I don't think that that would be a very workable solution; initscripts are
normally not run interactively, and so having them write stuff to stderr is
frowned upon. Ultimately, there just isn't any good solution for this in PG
7.*; which is why the upstream developers did a substantial amount of work to
fix it in 8.0.
There are also policy issues. With the goal of minimizing risk of change for
deployed systems, and in response to customer and partner requirements, Red Hat
takes a conservative approach when evaluating changes for inclusion in
maintenance updates for currently deployed products. The primary objectives of
update releases are to enable new hardware platform support and to resolve
critical defects. I don't think I could get approval for putting a short-term
hack for this problem into RHEL4.