Lamar Owen <lamar.owen@wgcr.org> writes:
> For RH 6.0: [ correct results ]
> for RH 6.1 (fresh install):
> column1
> -------
> 1
> 100
> 11
> 2
> So, I moved the physical database structure over from the 6.1 machine to
> the 6.0 machine and redid the select: the right results.
> The RedHat 6.0 machine is running the same exact postgres binaries that
> the RedHat 6.1 machine is running -- the 6.5.3-2nl rpms were built on my
> home RedHat 6.1 machine.
Wow. Same data files, same binaries, different results. Sure looks
like the finger is pointing at 6.1's libc. (I'm assuming that the
binaries make use of a shared-library libc, not statically-linked-in
routines, right?)
> Ok, hackers:
> What library routine is used to do the order by in this case?
If you compiled with USE_LOCALE, it's strcoll(); if not, strncmp().
See varstr_cmp() in src/backend/utils/adt/varlena.c.
> Looking at the regression diffs, it is obvious that there is a collation
> problem here. But where is this collation sequence problem coming from?
> (Note that the 6.5.3-2nl RPMs are built without locale support.)
OK...
Your regression failures show collation problems in all three of bpchar,
varchar, and name. (But curiously, not for text ... hmm ...). bpchar
and varchar both use varstr_cmp(), but namelt just calls strncmp
unconditionally --- see adt/name.c. So the evidence is looking very
strong that strncmp has got some kind of problem on RH 6.1.
regards, tom lane
