Thread: elog.c logic bug?

I have just been staring for some time at the logic in 
src/backend/utils/error/elog.c:send_message_to_server_log(), which 
contains this fragment near the end:


   /* Write to stderr, if enabled */   if ((Log_destination & LOG_DESTINATION_STDERR) || whereToSendOutput 
== DestDebug)   {
#ifdef WIN32
       /*        * In a win32 service environment, there is no usable stderr. 
Capture        * anything going there and write it to the eventlog instead.        *        * If stderr redirection is
active,it's ok to write to stderr 
 
because        * that's really a pipe to the syslogger process. Unless we're 
in the        * postmaster, and the syslogger process isn't started yet.        */       if ((!Redirect_stderr ||
am_syslogger|| (!IsUnderPostmaster && 
 
SysLoggerPID==0)) && pgwin32_is_service())           write_eventlog(edata->elevel, buf.data);       else
#endif           fprintf(stderr, "%s", buf.data);   }
   /* If in the syslogger process, try to write messages direct to file */   if (am_syslogger)
write_syslogger_file(buf.data,buf.len);
 

ISTM that this is a bug - the last statement should be inside the STDERR 
block above, the last part of which would then read:
   /* If in the syslogger process, try to write messages direct to file */   if (am_syslogger)
write_syslogger_file(buf.data,buf.len);  else       fprintf(stderr, "%s", buf.data);
 

If not I have missed something - why would the syslogger be trying to 
write to its output (possibly for the second time) regardless of what 
Log_destination is set to?

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> If not I have missed something - why would the syslogger be trying to 
> write to its output (possibly for the second time) regardless of what 
> Log_destination is set to?

You're mistaken: within the syslogger process, stderr doesn't point to
the same place as the target file (it's normally the same as the
original postmaster stderr).  The reason the code is set up to try to
write both stderr and the target file is to maximize the chance that an
internally generated error in syslogger will get reported *someplace*.
        regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> If not I have missed something - why would the syslogger be trying to 
>> write to its output (possibly for the second time) regardless of what 
>> Log_destination is set to?
>>     
>
> You're mistaken: within the syslogger process, stderr doesn't point to
> the same place as the target file (it's normally the same as the
> original postmaster stderr).  The reason the code is set up to try to
> write both stderr and the target file is to maximize the chance that an
> internally generated error in syslogger will get reported *someplace*.
>
>             
>   

OK, thanks, I'll try to make that a bit clearer in a comment.

cheers

andrew