stderr piping under win32

Tom Lane wrote:
> Yuck.  Count on Microsoft for incompetent implementations of basic
> facilities :-(

I won't contradict.

> 
>>I'll be implementing this as a postmaster thread waiting on multiple
>>pipes (one for each client).
> 
> 
> If you do, I'll reject it out of hand.  The point of having a separate
> postmaster process is for it to be as bulletproof and uncrashable as
> possible.  Putting such a thing as that into the postmaster will degrade
> its reliability significantly.

We're not in linux. Threading is much more stable and calculatable 
compared to **ix (if the software part is designed for that, I'm not 
talking about complete backends), and the code would be quite short (we 
already have threads in the postmaster...)
It's just a main loop scanning for data appearing in a pipe, and 
forwarding into another file handle. shmem free, of course.

> 
> If the multithreading were done in a separate logger subprocess, this
> complaint wouldn't apply, but I was kinda hoping that we could make the
> logger just as simple and high-reliability as the postmaster :-(

I agree, the last process to die should be the logger to catch as many 
information as possible. This is the case in linux, at least the logger 
subprocess will die after the postmaster (IsPostmasterAlive). We could 
even invent an additional delay after postmaster exit, to catch final 
pgstat output.

Hm. The problem is, if a subprocess should scan that stderr pipes, the 
postmaster must know those handles as well to hand it over to the new 
child. This means, it must create them inheritable. We certainly don't 
want to inherit 100 pipe handles to any subprocess, if configured for 
100 max clients. I'll think about that.

> Are there any other alternatives?

I tried really hard. Alternative is not to use stderr at all, and write 
explicitely to individual pipes. That's really the same.


> We could apply the patch and make it #ifndef WIN32 for now,

The logger subprocess patch is already made WIN32 ready (ignoring file 
logging stuff).

This thread is *not* mainly about the syslogger stuff, initially I 
selected a misleading title; sorry. As I said, even standard command 
line redirection of stderr is subject to M$ destruction.


> PS: is it possible that the observed unreliability is not Redmond's
> fault, but is something wrong with our pg_pipe code?


No, I have a very small test program (pg*-free) compiled with gcc or 
vc6, which shows the stderr problem. pgpipe doesn't work anyway, because 
it creates a pair of sockets, but M$ won't redirect stderr to sockets, 
only files or pipes. I wonder why pgpipe is implemented like this, maybe 
because the initial coder didn't know how to inherit handles obtained by 
_pipe(...). Documentation is really not helpful on that topic. After 
all, I found out by complete inspection of possibilities.

Regards,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org