Re: BUG #13594: pg_ctl.exe redirects stderr to Windows Events Log if stderr is redirected to pipe
От | Egon Kocjan |
---|---|
Тема | Re: BUG #13594: pg_ctl.exe redirects stderr to Windows Events Log if stderr is redirected to pipe |
Дата | |
Msg-id | 55E803D1.9090004@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13594: pg_ctl.exe redirects stderr to Windows Events Log if stderr is redirected to pipe (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-bugs |
On 1.9.2015 3:43, Michael Paquier wrote: > On Mon, Aug 31, 2015 at 11:56 PM, Egon Kocjan wrote: >> 2) However there is no output on stderr when pg_ctl is running as a >> subprocess of a service. So I would still have to patch pg_ctl if I want >> stderr. I haven't looked into elog.c yet, maybe stderr from there would be >> good to have as well? So far, pg_ctl output and pg_logs\* was enough for me >> to debug the installations. Technically, I could also monitor Windows event >> log and dump events on the fly into my report file. But it seems simpler to >> just patch PostgreSQL locally to force stderr and reuse all the logic from >> the Unix port... > I wished we had such a switch a couple of times and I have as well > some code paths that would benefit a redirection of those logs to > stderr instead of the event log. Still this sounds like a new feature > to me. Hence, what about for example adding a Windows-only option that > can be used to enforce where logs are redirected, let's say > --log-output with the following values: > - default, which is what we have now > - stderr, to enforce the output to stderr > - eventlog, to enforce redirection to the event logs. > Would you like to work on this patch? > Yes, I would start with pg_ctl itself. Then we can look into what else needs to be done for the backend, I'm not yet 100% sure how it all fits together. Regards Egon
В списке pgsql-bugs по дате отправления: