"Magnus Hagander" <mha@sollentuna.net> writes:
>> I dislike going through write_stderr because it requires an extra,
>> useless gettext() call,
> It does?
First thing it does.
> Isn't buf.data already "gettextified"?
Yeah; the gettext() call is against the "%s". (If it did gettext() on
the buffer data it would be outright wrong.) Useless, but potentially
a cycle-sucker under high log volume.
>> but you can't assume that every log message the system ever prints
>> is going to be under 2K.
> We're not assuming that!
Yes you are (and no the "it's user error" argument doesn't impress me).
It's trivial to work around both these problems anyway; just a matter
of repeating the logic in-line instead of trying to use write_stderr.
The issue that's actually bothering me is:
>> 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.
> 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?
regards, tom lane
