Multiple reporting of syslogger errors - Mailing list pgsql-hackers

From Tom Lane
Subject Multiple reporting of syslogger errors
Date
Msg-id 338.1535303331@sss.pgh.pa.us
Whole thread Raw
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Alexander Kukushkin
Date:
Subject: Postmaster doesn't send SIGTERM to bgworker during fast shutdown whenpmState == PM_STARTUP
Next
From: Tom Lane
Date:
Subject: Something's busted in plpgsql composite-variable handling