Reinhard Max <reinhard@m4x.de> writes:
> On Thu, 20 Sep 2012 at 11:06, Tom Lane wrote:
>> Well, I would have no objection to changing pg_ctl so that it
>> redirects the postmaster's stdout/stderr when a -l switch is given
>> (actually, I thought it did that already...).
> Well, going that route forces me to either introduce yet another log
> file for the user to look into when something goes wrong with
> PostgreSQL, or to suppress that information completely (when using -l
> /dev/null). I think it is common practice for daemons to report early
> errors to stderr (so that the user starting the serivice gets to see
> them on the terminal) and after successfull startup redirect to
> /dev/null and log to syslog or their own logging mechanism.
Well, at least in the Fedora/RHEL packages I had such an additional log
file for years. Printing complaints to "the terminal" turns out to not
be tremendously useful in service start scripts, because even if there's
somebody watching the console during boot, the info tends to fly
offscreen pretty quick. (systemd finally improved that by connecting
services' stdout/stderr to syslog by default --- but it's still not
going to the user's screen.)
>> I do object to changing the logger's behavior as you suggest,
>> because that will break use-cases that work today. One that I've
>> used personally is adding "fprintf(stderr)" calls in the logger for
>> debugging the logger itself.
> Do you also have use cases in mind that are relevant for end users of
> PostgreSQL who never even look into the source code?
Sure. Under systemd the logger's stderr will go to /var/log/messages.
Admittedly, it shouldn't ever print anything there during normal
operation, but we don't have control over all the code in the process.
For instance, if glibc were to detect malloc-arena corruption, its
complaints about that would end up in /var/log/messages. Under your
proposal they'd end up in /dev/null.
regards, tom lane