Skip site navigation (1) Skip section navigation (2)

Re: Logger subprocess for win32

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: Logger subprocess for win32
Date: 2004-07-29 14:30:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
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
facilities :-(

> 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 LaneDate: 2004-07-29 14:49:46
Subject: Re: [HACKERS] win32 crash in initdb
Previous:From: Korea PostgreSQL Users' GroupDate: 2004-07-29 14:06:17
Subject: Re: win32 crash in initdb - it has still problems.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group