Tatsuo Ishii [EMAIL PROTECTED] writes:
Can we distinguish mingw case from others so that we could ifdef out
the extra fflush()?
Isn't the right fix a single-spot patch to force stderr into unbuffered
mode? It's supposed to be that way already per spec. I could see a
one-or-two-line patch to
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
This is a pretty major user-visible change. While I'm strongly in
favour of it it seems like there ought to be some documentation file
touched by this, no? Or have I missed it?
In my opinion, and possibly that of others who have
Tom Lane [EMAIL PROTECTED] writes:
It's a release-note item ... assuming that it doesn't get reverted in
the near future. Could we have some attention to the all-red buildfarm?
It's not just a bug. There's code missing.
The code seems to assume that all custom variables are strings. There
On Tue, Mar 13, 2007 at 05:09:15PM +0900, ITAGAKI Takahiro wrote:
Tatsuo Ishii [EMAIL PROTECTED] wrote:
Can we distinguish mingw case from others so that we could ifdef out
the extra fflush()?
The buffered stderr might be a bug of mingw
After a little research, I found that MSDN
On Tue, Mar 13, 2007 at 08:22:17AM +, Gregory Stark wrote:
The code seems to assume that all custom variables are strings. There are
about half a dozen Assert(variable-vartype == PGC_STRING) throughout the
patch. That's not true, plperl's use_strict is a boolean and we have
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Was this revisited?
Arranging the tests has taken me longer than I thought, but I now
finally have the hardware and DBT-2 set up. I just finished a pair of 2h
tests with autovacuum off, and continuous vacuum of the stock table. I'm
trying to
Heikki Linnakangas wrote:
I ran two 24h test runs with DBT-2, one with the patch and one without.
To get comparable, predictable results, I turned autovacuum off and run
a manual vacuum in a loop on the stock-table alone.
As expected, the steady-state of the stock table is smaller with
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I ran two 24h test runs with DBT-2, one with the patch and one without.
To get comparable, predictable results, I turned autovacuum off and run
a manual vacuum in a loop on the stock-table alone.
As expected, the steady-state of the stock
Gregory Stark [EMAIL PROTECTED] writes:
It's not just a bug. There's code missing.
The code seems to assume that all custom variables are strings. There are
about half a dozen Assert(variable-vartype == PGC_STRING) throughout the
patch. That's not true, plperl's use_strict is a boolean and
Tom Lane wrote:
The thing that I was wondering about is the same Joachim mentioned:
how is it that the regression test ever worked? The answer is that
it's not really testing custom variables, because it doesn't try to
set plperl.use_strict until after plperl has been loaded into the
current
On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
It's not just a bug. There's code missing.
The code seems to assume that all custom variables are strings. There are
about half a dozen Assert(variable-vartype == PGC_STRING) throughout the
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote:
Well, they *are* strings as long as they're custom. Once a
DefineCustomFoo has been executed, there (should be) no difference
between a custom variable and a hard-wired one.
The code in
On Tue, Mar 13, 2007 at 11:08:52AM -0400, Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote:
Well, they *are* strings as long as they're custom. Once a
DefineCustomFoo has been executed, there (should be) no difference
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 11:08:52AM -0400, Tom Lane wrote:
My point here that you shouldn't be using var-group to make any
semantic choices. That's supposed to be a label for user convenience,
nothing else.
Then what is the criterion to tell what is
On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
Then what is the criterion to tell what is a custom variable and what isn't?
Why do you need to tell that? IMHO, once the DefineCustomFoo function
has been executed, it should be exactly like any other variable (other
than having a
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
Why do you need to tell that? IMHO, once the DefineCustomFoo function
has been executed, it should be exactly like any other variable (other
than having a funny name).
For example for the
Updated patch:
I went through the high traffic areas and levelled them up to using the new
macros to avoid detoasting smaller arguments. They key areas are really
btree operators since they have a noticeable effect on sorts, especially index
builds, when the data being sorted fits in memory.
Please see the attached version 4.4 of HOT WIP patch. I have
fixed couple of bugs in the earlier version posted. Other than
that there are not any significant changes in the patch.
The row-level fragmentation had a bug where we were
unintentionally sorting the line pointers array more than
18 matches
Mail list logo
