Greg Stark <gsst...@mit.edu> writes:
> ISTM the danger is that someone looks at the regular logs and isn't
> aware that some messages went to someplace else. In which case
> bleating to the someplace else is unhelpful.
Yes, that's my problem with it in a nutshell. Anybody who is smart
enough to look at the original stderr doesn't need the warning;
all it does is distract from the real messages.
> Perhaps it would be more useful if
> it set a flag and then once the regular logs are set up you output a
> regular warning that some errors were generated prior to switching and
> were sent to stderr.
That'd be nice, but I'm unconvinced that it is feasible. The uncaught
messages might have come from subprocesses, or from library code that
isn't polite enough to go through elog. We go to a lot of trouble to
be able to capture all such traffic once the logger process is alive.
Pretending that we can tell you about traffic we didn't capture
seems to me to be likely to instill a false sense of confidence.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
