Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
> 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.
Yuck. Count on Microsoft for incompetent implementations of basic
> 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.
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 :-(
Are there any other alternatives?
We could apply the patch and make it #ifndef WIN32 for now, but given
the lateness of the hour I'm inclined to say that we'd best postpone
the whole thing to 7.6 ... certainly I'm running out of time to review
it before the end of the month, even if we had a finished patch now.
regards, tom lane
PS: is it possible that the observed unreliability is not Redmond's
fault, but is something wrong with our pg_pipe code?
In response to
pgsql-hackers-win32 by date
|Next:||From: Tom Lane||Date: 2004-07-29 14:49:46|
|Subject: Re: [HACKERS] win32 crash in initdb |
|Previous:||From: Korea PostgreSQL Users' Group||Date: 2004-07-29 14:06:17|
|Subject: Re: win32 crash in initdb - it has still problems.|