From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | mario(at)emmenlauer(dot)de |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15363: Logging unexpectedly goes to system event log instead of stderr |
Date: | 2018-09-04 23:23:08 |
Message-ID: | 7448.1536103388@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> My question is not about the failed startup, but about the logging. I am
> confused why the permission problem was logged to Windows system log instead
> to stdout/stderr? My postgresql.conf is the default from initdb.exe and
> contains only the default #log_destination = 'stderr'. The documentation at
> https://www.postgresql.org/docs/current/static/runtime-config-logging.html
> says "The default is to log to stderr only".
elog.c interprets "write to stderr" like this:
#ifdef WIN32
/*
* In a win32 service environment, there is no usable stderr. Capture
* anything going there and write it to the eventlog instead.
*
* If stderr redirection is active, it was OK to write to stderr above
* because that's really a pipe to the syslogger process.
*/
else if (pgwin32_is_service())
write_eventlog(edata->elevel, buf.data, buf.len);
#endif
else
write_console(buf.data, buf.len);
I imagine that pgwin32_is_service was yielding true in your situation.
Unfortunately, I don't know if there's much we can do about this;
as I recall, there's no good way for us to discover whether stderr
output goes anywhere useful.
(Hmm, looking at the code, it could also be that pgwin32_is_service
was reporting failure. I'm not sure whether it's a great idea that
we're effectively assuming we're a service when we can't really
tell.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2018-09-05 04:33:13 | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |
Previous Message | PG Bug reporting form | 2018-09-04 21:30:18 | BUG #15363: Logging unexpectedly goes to system event log instead of stderr |