Thread: BUG #3647: error message logged to stderr only, not redirect logfile

The following bug has been logged online:

Bug reference:      3647
Logged by:          Michael Charnoky
Email address:      noky@nextbus.com
PostgreSQL version: 8.1.8
Operating system:   Linux (Fedora Core 3) 2.6.17
Description:        error message logged to stderr only, not redirect
logfile
Details:

I think I found a logging bug in PostgreSQL 8.1.8.  Didn't see a mention
about a fix in the release notes for 8.1.9 or .10, so this is probably still
a bug.

Using:
 log_destination = 'stderr'
 redirect_stderr = on

If PostgreSQL fails to start (eg: the OS's SHMMAX wasn't set high enough to
handle the requested 'shared_buffers'), the error message gets logged to
stderr only and not the logfile in 'log_directory'.  I would like to simply
redirect stderr to /dev/null and just rely on the logfiles, but am worried
that I might miss some error messages.

Here is an example.  This was logged to stderr (captured to file) but not
the log file in 'log_directory'):

2007-10-01 08:07:49.857 PDT: FATAL:  could not create shared memory segment:
Invalid argument
2007-10-01 08:07:49.857 PDT: DETAIL:  Failed system call was
shmget(key=5432001, size=424984576, 03600).
2007-10-01 08:07:49.857 PDT: HINT:  This error usually means that
PostgreSQL's request for a shared memory segment exceeded your kernel's
SHMMAX parameter.  You can either reduce the request size or reconfigure the
kernel with larger SHMMAX.  To reduce the request size (currently 424984576
bytes), reduce PostgreSQL's shared_buffers parameter (currently 50000)
and/or its max_connections parameter (currently 250).
        If the request size is already small, it's possible that it is less
than your kernel's SHMMIN parameter, in which case raising the request size
or reconfiguring SHMMIN is called for.
        The PostgreSQL documentation contains more information about shared
memory configuration.

"Michael Charnoky" <noky@nextbus.com> writes:
> If PostgreSQL fails to start (eg: the OS's SHMMAX wasn't set high enough to
> handle the requested 'shared_buffers'), the error message gets logged to
> stderr only and not the logfile in 'log_directory'.  I would like to simply
> redirect stderr to /dev/null and just rely on the logfiles, but am worried
> that I might miss some error messages.

Sorry, this request is hopeless.  While we could possibly start
redirecting a bit earlier than we do now, that wouldn't eliminate the
basic problem.  There will *always* be some startup-time messages that
are vulnerable to this problem --- what if startup fails before it can
fork the log collector and redirect stderr, or even before it can read
the configuration file to find out it is supposed to redirect?

A good scheme is to use redirect_stderr, but also have the postmaster's
original stdout/stderr directed to a backup log file.  You need not
worry about rotation of the backup log file, since it isn't expected to
accumulate much data, but it needs to be there to backstop the log
collector for startup problems and failures of the log collector itself.

            regards, tom lane