Bug 159503
Summary: | initscript hides FATAL messages from postmaster | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Anchor Systems Managed Hosting <managed> |
Component: | postgresql | Assignee: | Tom Lane <tgl> |
Status: | CLOSED NEXTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | hhorak |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-30 19:45:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Anchor Systems Managed Hosting
2005-06-03 08:09:35 UTC
(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 starting. (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 alternatives. 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 a file? 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. |