Magnus Hagander [EMAIL PROTECTED] writes:
Here is an updated patch, that should take care of this. Tested that it
solves the problem reported.
I compared this to the version Bruce applied earlier and decided that
his version was good. I don't think we should change the original logic
that
Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: den 27 februari 2005 02:04
To: Magnus Hagander
Cc: Tom Lane; PostgreSQL-patches; Andreas Pflug
Subject: Re: [PATCHES] [BUGS] BUG #1466: #maintenace_work_mem = 16384
Patch applied. Thanks.
I assume this is not for 8.0.X
Patch applied. Thanks.
I assume this is not for 8.0.X.
---
Magnus Hagander wrote:
The proposed test on Redirect_stderr looks pretty fishy too; for one
thing it will almost certainly not be the right thing
inside
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
Can defaults be set to the result of a function?
By power-on default I mean the value that the variable is assigned as
its static initializer. That has to be a link-time constant (at least
in C ...). Anything else will mean misbehavior if an error occurs
before the GUC code itself has been
Magnus Hagander [EMAIL PROTECTED] writes:
What do you think of the following as a fix?
I dislike going through write_stderr because it requires an extra,
useless gettext() call, and because in the Windows case it imposes
an arbitrary length limit that is certain to be exceeded. The length
limit
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
