logger subprocess including win32

Started by Andreas Pflugabout 22 years ago5 messagespatches
Jump to latest
#1Andreas Pflug
pgadmin@pse-consulting.de

Attached the patch, an orgy in #ifdefs, decorated with various indents
and crlf line ends (glad we have pgindent).

Remarks:
Log_destination for win32 is set to file, because stderr is equivalent
to /dev/null for services. This doesn't reflect correctly in
postgresql.conf.sample.

Log_destination=eventlog is like logging to /var/log/messages, you'd
make the sysadmin your enemy if he finds his app log flooded with
"NOTICE: created implicit index for pk". FYI: The size of the event log
is limited (default: 512k), cyclic overwriting can be selected, but *no*
rotation. Only really important messages should go there, not standard
logging. OTOH, really important messages *must* go there, so I changed
FATAL and PANIC messages to eventlog unconditionally.

Regards,
Andreas

Attachments:

logfile.difftext/x-patch; name=logfile.diffDownload+135-15
syslogger.ctext/x-csrc; name=syslogger.cDownload
syslogger.htext/x-chdr; name=syslogger.hDownload
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andreas Pflug (#1)
Re: logger subprocess including win32

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, but I don't know how to do the
equivalent in this threaded scheme you've devised for Windows.

(Why is the separate thread needed, again?)

regards, tom lane

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andreas Pflug (#1)
Re: logger subprocess including win32

Andreas Pflug <pgadmin@pse-consulting.de> writes:

Tom Lane wrote:

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

In pipeThread:

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

Got it. And there's no reason that the pipe thread can't do exit(0)
for itself? Might be cleaner to make it set a flag for the main line
to look at ...

regards, tom lane

#4Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Tom Lane (#2)
Re: logger subprocess including win32

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

#5Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Tom Lane (#3)
Re: logger subprocess including win32

Tom Lane wrote:

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

Got it. And there's no reason that the pipe thread can't do exit(0)
for itself?

Not really. All threads are equivalent.
BTW, should there be a last NOTICE "syslogger shutting down"?

Regards,
Andreas