The attached tiny patch forces C locale on the temp location built by
pg_regress - it fixes recent regression problems observed on Windows.
cheers
andrew
Index: src/test/regress/pg_regress.sh
===
RCS file:
Andrew Dunstan [EMAIL PROTECTED] writes:
The attached tiny patch forces C locale on the temp location built by
pg_regress - it fixes recent regression problems observed on Windows.
I don't think this is really a good idea, because it makes it impossible
to run the tests any other way.
If
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The attached tiny patch forces C locale on the temp location built by
pg_regress - it fixes recent regression problems observed on Windows.
I don't think this is really a good idea, because it makes it impossible
to run the
Tom Lane weote:
If you're speaking of the current buildfarm results from loris, I'm
unconvinced that that's a locale problem --- the opr_sanity results
in particular shouldn't be locale-sensitive.
It is locale problem, I have 9 failures (like loris) with my locale and
0 failures with
Andrew Dunstan [EMAIL PROTECTED] writes:
Both Petr and I have seen that with --no-locale set the regression set
gets a clean run. If you want us to dig deeper into those 9 failures,
just tell us what to look for.
Well, for example, the first diff in the opr_sanity test appears to
indicate
Tom Lane wrote:
And why did it suddenly start failing today? My bet is those UTF8/UTF16
routines we put in are a few bricks shy of a load yet, and that
--no-locale fixes it by preventing those routines from being used.
You mean the changes in varlena.c? Should I try reverting it and
Petr Jelinek [EMAIL PROTECTED] writes:
(it's same as loris, I posted it just as evidence that --no-locale fixes
all failures)
I think --no-locale is masking a problem with the recently-installed
UTF16-based comparison code. See my response to Andrew just now.
regards,
Andrew Dunstan [EMAIL PROTECTED] writes:
You mean the changes in varlena.c? Should I try reverting it and see
what happens?
Sure. If we'd been seeing these failures all along, I might think that
--no-locale was a good solution, but since they just popped up I think
suspicion has to fall on
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] writes:
You mean the changes in varlena.c? Should I try reverting it and see
what happens?
Sure. If we'd been seeing these failures all along, I might think that
--no-locale was a good solution, but since they just popped up I think
suspicion
Tom Lane wrote:
That's it alright. When I change the ifndef in varlena.c to #ifndef xxxWIN32
the regression tests sail through.
OK, so what is your default locale on that machine? In particular, is
it UTF16-based?
initdb picks up: English_United States.1252
cheers
andrew
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
OK, so what is your default locale on that machine? In particular, is
it UTF16-based?
initdb picks up: English_United States.1252
Yup. So it was trying to use this little hack:
/* Win32 has strncoll(), so use it to
11 matches
Mail list logo
