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 us
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 said:
>> 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 the latest patches.
> That's it alright. When I change the
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
>
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
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.
regar
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
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
indicat
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 --no-loc
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
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 y
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: /home/cvsmirror/pgsql/s
12 matches
Mail list logo
