Tom Lane wrote:
> It might be best to just leave syslogFile open --- it should be properly
> flushed and closed by exit() anyway, no?
Agreed.
> Windows treats _IOLBF the same as _IOFBF, which we don't want.
> Okay, ifdef time.
:->
>>An observation I didn't track down so far:
>>Some LOG messages (e.g. the final logger shutdown, or "received fast
>>shutdown request") don't have proper CRLF line ending in win32, but only
>>LF.
>
>
> Weird. No ideas about that. Can you determine whether the data coming
> through the pipe has the problem?
It has, that's where I noticed. It is restricted to the postmaster and
the syslogger; all other processes ereport correctly.
Apparently, this is a mixture of binary and text file mode. Initially,
stderr is in text mode. When redirecting with dup2, it will be binary;
this must be corrected with
dup2(_open_osfhandle(...., _O_APPEND | _O_TEXT), ...
which solves the issue for postmaster. Child processes will have stderr
in text mode automatically, even if inherited and redirected into a pipe
(which is always binary).
Now, the pipe ReadFile will receive completely formatted data, which
must be written binary (otherwise we will get CRCRLF), OTOH, the
logger's calls to write_syslogger_file should write in text mode or
replace \n by \r\n. Seems we need another function for elog to call.
>
> Why doesn't it work? Do we just need a different spelling of
> "/dev/null" for Windows?
Er, /dev/null? no such beast under win32.
Just checked, closing stderr works.
>
>>Finally, you don't seem to be a friend of a logfile rotation user
>>trigger...
>
>
> Nope, I'm not. I think it's a bad solution to a nonexistent problem.
> The logger's control parameters are more than sufficient. Furthermore,
> we'd really prefer that the logger doesn't ever crash (the restart
> business is a bit ticklish) and so the fewer features it has, the better.
It's no additional feature, it's just using an existing communication
path (signal), which has to be handled anyway, to setting an existing
flag. The code path for sighup is certainly much larger.
Regards,
Andreas
