Re: BUG #15363: Logging unexpectedly goes to system event log instead of stderr
От | Tom Lane |
---|---|
Тема | Re: BUG #15363: Logging unexpectedly goes to system event log instead of stderr |
Дата | |
Msg-id | 7448.1536103388@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #15363: Logging unexpectedly goes to system event log instead ofstderr (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #15363: Logging unexpectedly goes to system event log insteadof stderr
|
Список | pgsql-bugs |
=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.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
В списке pgsql-bugs по дате отправления: