Re: logger subprocess including win32 - Mailing list pgsql-patches

From Andreas Pflug
Subject Re: logger subprocess including win32
Date
Msg-id 4112A805.4040902@pse-consulting.de
Whole thread Raw
In response to Re: logger subprocess including win32  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: logger subprocess including win32
List pgsql-patches
Tom Lane wrote:
> Andreas Pflug <pgadmin@pse-consulting.de> writes:
>
>>Attached the patch, an orgy in #ifdefs, decorated with various indents
>>and crlf line ends (glad we have pgindent).
>
>
> I spent a fair amount of time fooling with this, trying to extract
> something that I trusted enough to apply at this late date, but got
> stuck on one point.  Exiting when the postmaster dies is *not* good
> enough; we want the logger to stick around until the last process
> upstream of the logger pipe is gone.  In the Unix case we can detect
> this by watching for EOF on the pipe,


I saw strange errnos coming from that pipe, i.e. EMFILE. I'm not sure if
EOF is really reliable.


  but I don't know how to do the equivalent in this threaded scheme
you've devised for Windows.

if (realStdErr !0 NULL)
{
    ...
}
#ifdef WIN32
CloseHandle(writePipe);
#else
close(syslogPipe[1]);
#endif


You probably found out yourself.


In pipeThread:

if (!ReadFile(...))
{
    DWORD error = GetLastError();
    if (error == ERROR_HANDLE_EOF)
       exit(0);

/* errno is not set */
    ereport(COMERROR,
    errmsg("could not read from system logger pipe: %d", error)))}
}


> (Why is the separate thread needed, again?)

On unnamed pipes, WaitForSingleObject does not work (it always reports
"signaled", so the blocking ReadFile won't allow for
sighup/IsPostmasterRunning; select is for sockets only).



Regards,
Andreas



pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: logger subprocess including win32
Next
From: Tom Lane
Date:
Subject: Re: logger subprocess including win32