Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (a) that really shouldn't be exported out of postmaster.c, and (b) it is
>> not readily available to child backends is it?
> It's already used in elog.c in Win32 code:
> if ((!Redirect_stderr || am_syslogger ||
> (!IsUnderPostmaster && SysLoggerPID==0)) &&
> pgwin32_is_service())
> write_eventlog(edata->elevel, buf.data);
> Child backends might have an out of date version if we restart the
> Syslogger, but would that matter in this case?
This code is already too ugly to live :-(.
But aside from esthetics, there is a functional reason to have a
separate flag variable. Consider the transient state where the
syslogger has failed and we are trying to start a new one. If the
postmaster wishes to elog anything (like, say, the log entry about
the syslogger having failed) in this interval, then it *should*
use the chunk protocol, because we expect that the data will
eventually be eaten by the new syslogger.
I think offhand that the correct semantics of the flag are "we have
redirected our original stderr into a pipe for syslogger", and in
fact that we should transition the output format exactly at the
instant where we do that; the starting of the child process happens
at a slightly different time, and restarting of the child (if needed)
is yet a different issue.
Another thing that tracking such a flag would help us clean up is
the syslogger's own elogging behavior. IIRC the "original" syslogger
is launched with its stderr pointing to the original stderr, and so
it's useful for any messages generated by syslogger itself to be copied
onto that stderr. After a relaunch, though, this is no longer possible
and it'd probably be best if syslogger doesn't even try writing to its
stderr.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
