>>> The proposed test on Redirect_stderr looks pretty fishy too; for one
>>> thing it will almost certainly not be the right thing 
>inside the stderr
>>> logger subprocess itself.
>> Could you explain further what the issue is there? 
>Inside the logger subprocess, Redirect_stderr is guaranteed true (since
>it'll be inherited from the postmaster) and therefore the proposed
>change ensures that anything the logger might want to complain about
>goes to the original stderr, ie, into the bit bucket rather than
>someplace useful.  Perhaps something like
>       if ((!Redirect_stderr || am_syslogger) && pgwin32_is_service())
>would be reasonable.

<snip lots of others>

Here is an updated patch, that should take care of this. Tested that it
solves the problem reported.

>> There is special code in the send_message_to_server_log 
>function to make
>> sure it's written directly to the file.
>If the logger is complaining, it's quite possibly because it's 
>unable to
>write to its file.  Now that you mention it, doesn't this code go into
>infinite recursion if write_syslogger_file_binary() tries to ereport?

I haven't looked at this part, it appears a separate (but closely
related) issue.

Perhaps Andreas can comment on this?


Attachment: stderr.patch
Description: stderr.patch

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to