>> What do you think of the following as a fix?
>
>I dislike going through write_stderr because it requires an extra,
>useless gettext() call,

It does? Isn't buf.data already "gettextified"? write_stderr just calls
vfprintf. Or is this an example of me not knowing how gettext works?


> and because in the Windows case it imposes
> an arbitrary length limit that is certain to be exceeded.
> The length
>limit is probably OK for the existing limited usages of write_stderr,
>but you can't assume that every log message the system ever prints
>is going to be under 2K.

We're not assuming that!
If the system is configured to log to eventlog, this code is never
called.
If the system is configured to log to a file (redirect_stderr), this
code is never called.

It is *only* called when:
- System has not read it's full configuration yet (which is the case we
are trying to address)
- System is configured for logging to stderr *without* capturing it to a
file *and* running as a service. I'd argue this is a configuration
error.

>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?

There is special code in the send_message_to_server_log function to make
sure it's written directly to the file.


//Magnus

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

"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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org