Re: BUG #7559: syslogger doesn't close stdout and stderr - Mailing list pgsql-bugs

From Reinhard Max
Subject Re: BUG #7559: syslogger doesn't close stdout and stderr
Date
Msg-id alpine.LNX.2.00.1209201727560.10793@albrecht.home.m4x.de
Whole thread Raw
In response to Re: BUG #7559: syslogger doesn't close stdout and stderr  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, 20 Sep 2012 at 11:06, Tom Lane wrote:

> (I assume you mean pg_ctl not pg_init?)

Yes, sorry for the confusion.

> 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.

> 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? If not (i.e. if
the use cases are more developer-centric), I think the default should
be to let the logger do the redirection and having a command line
switch or postgresql.conf variable to suppress it for debugging
purposes.

cu
     Reinhard

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes
Next
From: Mayank Mittal
Date:
Subject: Re: BUG #7562: could not read block 0 in file "base/16385/16585": read only 0 of 8192 bytes