I noticed while testing the fix for Alexander Kukushkin's complaint that
if the syslogger process detects a problem (e.g., failure to open a new
log file) while log_destination is set to "csvlog", the error report
actually goes to THREE places. It gets spit out to csvlog, *and* to the
stderr log file, *and* to the original postmaster stderr. This seems
excessive.
The reason for the stderr log file output is that elog.c's
send_message_to_server_log has this hard-wired behavior:
/* If in the syslogger process, try to write messages direct to file */
if (am_syslogger)
write_syslogger_file(buf.data, buf.len, LOG_DESTINATION_STDERR);
The reason for the output to the original postmaster stderr is that
the stanza above that, beginning
/* Write to stderr, if enabled */
if ((Log_destination & LOG_DESTINATION_STDERR) || whereToSendOutput == DestDebug)
will always trigger in the syslogger because whereToSendOutput ==
DestDebug; we've forgotten to reset that to DestNone, as the postmaster
does immediately after forking the syslogger. Then, in the syslogger,
that stanza ends up in write_console() which writes to the inherited
stderr. (On the other hand, in Windows or other EXEC_BACKEND builds,
SubPostmasterMain will have done the reset, so that this doesn't occur
on those platforms.)
It seems to me to be a fairly clear bug that the syslogger process may
forget to set whereToSendOutput = DestNone depending on platform, so
I propose to fix that along with Kukushkin's problem.
However, I'm less sure about whether to change the hard-wired behavior
of writing syslogger errors to LOG_DESTINATION_STDERR regardless of
log_destination. It would seem more consistent to do that only if stderr
output is enabled in log_destination, but I wonder whether we made it work
like this intentionally. Or maybe it was intentional before we invented
csvlog, and nobody rethought it.
Comments?
regards, tom lane
