After many hours of investigation trying to get the logger subprocess
running in win32, I had to realize that win32 differences make it
impossible to implement it in a similar fashion. Moreover, only the
eventlog facility currently guarantees all elog messages to be logged
undisturbed, stderr does not.
After finding out which handles get inherited in which situation I
frequently found the output of the stderr catching pipe being garbled.
Especially the messages from the boot process were nearly completely
trunctated. A test program (10 childs writing every 0-100ms) showed that
redirecting stderr of several subprocesses into the same pipe will lead
to one process overwriting the other's output. This is in contrast to
Linux' behaviour. NB: this also applies if stderr is redirected on the
shell level.
Apparently, it's necessary to redirect all subprocesses stderr into
separate pipes, in order to read them atomically and write them
non-garbled to a single stderr (or file) output. I'll be implementing
this as a postmaster thread waiting on multiple pipes (one for each
client). In order to avoid redirecting and re-redirecting stderr in
postmaster every time a subprocess is launched, the pipe handled
assigned to that new process should be transferred using
read/write_backend_variables, and the new process does the actual
redirection.
Regards,
Andreas
