Dear Tom and all,
On 05.09.2018 01:23, Tom Lane wrote:
> =?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.)
Aaah! Yes things make sense now, looking at elog.c! Thanks.
But just to ask, is it so fatal for a service to print to console?
I recall from Windows XP that there was a buffer of several hundred
KB that could be filled before it eventually killed the application.
In case of my specific problem, it would have been really helpful if
either:
- a message on console would have pointed to the log redirection, or
- the fatal error (before program termination) would have been printed
on console, possibly in addition to the event log.
Would any of this make any sense to you?
All the best and thanks again,
Mario Emmenlauer
--
BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203
Balanstr. 43 mailto: memmenlauer * biodataanalysis.de
D-81669 München http://www.biodataanalysis.de/