Re: [HACKERS] ordering RH6.1

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Frans Van Elsacker <fve(at)atbib(dot)be>
Cc: pgsql-hackers(at)postgresql(dot)org, jbj(at)redhat(dot)com, gafton(at)redhat(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us
Subject: Re: [HACKERS] ordering RH6.1
Date: 1999-12-17 00:20:47
Message-ID: 385981DF.9762BFC8@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[Cristian, Jeff: we have a problem here. RedHat 6.1 Install versus
RedHat 6.0 upgraded to 6.1 behaves differently. Ideas of where to start
looking?]

Frans Van Elsacker wrote:
> But we received the same bad results as before.
> column1
> -------
> 1
> 100
> 11
> 2
> (4 rows)
>
> Any Idea ?

Ok, I bit the bullet and spent the whole day (plus or minus a couple of
hours) putting together a test bed. I have three machines in this
testbed:
1.) My production server, running Mandrake 5.3, Postgresql 6.5.3-2nl;
2.) My backup server, running RedHat 6.0, Postgresql 6.5.3-2nl;
3.) My development server, freshly installed with RH 6.1 + all updates,
PostgreSQL 6.5.3-2nl.

I have now reproduced the results. HOWEVER, my home machine didn't
reproduce the earlier results, and it is RedHat 6.1 (an upgrade from RH
6.0).

For Mandrake 5.3:

column1
-------
1
2
11
100
(4 rows)

For RH 6.0: ditto Mandrake 5.3.

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. The Mandrake 5.3 machine is running the RedHat
5.2 binaries built by the alternate boot set on the development server
(which is why it took most of the day to set things up....).

Ok, hackers:

What library routine is used to do the order by in this case?

I'm going to retry this exact set of queries again at home -- I wasn't
able to reproduce the last set of results -- but we'll see what happens
here.

Strange.

I'll see what I can find -- this also explains some strange regression
results I was mailed awhile back. In fact, let's try regression on the
RH 6.1 fresh install.... AND I AM GETTING FAILURES THAT I HAVE NEVER
GOTTEN AT HOME ON MY UPGRADE REDHAT 6.1!

Recap while I'm waiting for regression to finish:
The fresh install of RedHat 6.1 is from the exact same CD that I
upgraded my home box from RH 6.0. The ONLY difference is the fresh
install versus the upgrade -- same versions of PostgreSQL. I am going to
double check regression at home, but I have not seen these results
before, and I distinctly remember running regression at home. I'll keep
you all updated.

[Nine minutes later]

Failures: float8, geometry, select implicit, select having, and select
views. The regress.out and regression.diffs are attached. Float8 and
geometry are normal.

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.)

I'm going to go digging into a diff of my home machine versus this new
RH 6.1 install.
--
Lamar Owen
WGCR Internet Radio

Attachment Content-Type Size
regression.diffs text/plain 16.4 KB
regress.out application/x-unknown-content-type-out_auto_file 1.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 1999-12-17 00:31:23 Re: [HACKERS] Re: [PATCHES] createdb/dropdb fixes
Previous Message Frans Van Elsacker 1999-12-16 22:53:45 Re: [HACKERS] ordering RH6.1