stderr piping under win32
От | Andreas Pflug |
---|---|
Тема | stderr piping under win32 |
Дата | |
Msg-id | 41095584.8090702@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: Logger subprocess for win32 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers-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
В списке pgsql-hackers-win32 по дате отправления: