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

Logger subprocess for win32

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers-win32(at)postgresql(dot)org
Subject: Logger subprocess for win32
Date: 2004-07-29 11:13:56
Message-ID: 4108DBF4.9090509@pse-consulting.de (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
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

Responses

pgsql-hackers-win32 by date

Next:From: Merlin MoncureDate: 2004-07-29 12:31:15
Subject: Re: Sources
Previous:From: Anass HAMMEDIDate: 2004-07-29 10:47:22
Subject: Sources

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