>> 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
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
>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.
---------------------------(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