Re: Call for platform testing

> Windows/Cygwin Jason Tishler

Only the "privileges" test failed when running "serial_schedule". When
running "parallel_schedule" there are random failures with errors
"cannot access some file with a table/index/...". So I think that
PostgreSQL is OK, but the Cygwin/Windows layer is not. We should try to
find what's wrong when multiple backends are running.

system:
CYGWIN_NT-5.0 CERT 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown

with cygipc 1.11

Dan

>

Regression test on Irix 6.5.13 installed with MIPSPro 7.30

=======================
2 of 79 tests failed.
=======================
geometry and join

regression test on irix 6.5.12 with MIPSpro Compilers: Version 7.3.1.2m
(this platform is 8-r10000 ip25 processors, previous is 8 -r12000 ip35 processors)

=======================
2 of 79 tests failed.
=======================
again join and geometry(it also failed in postgres 7.1.3)

7.2b3 compiles and passes all tests on Linux/Sparc64. I updated the
regression test database.

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

Luis Amigo <lamigo(at)atc(dot)unican(dot)es> writes:
> again join and geometry(it also failed in postgres 7.1.3)

The join discrepancy is probably an artifact of your local qsort()
behaving slightly differently for equal keys than everyone else's.
Curious that it only affects these few queries, though.

Geometry differences in the low-order digits are par for the course.
I wouldn't even stop to think about it, except that I see that you
are already using a platform-specific geometry comparison file
(geometry-irix.out). Some digging in the CVS logs and mail archives
shows that that file was submitted by Pete Forman in Oct 2000, and
he was using

> Architecture (example: Intel Pentium) : SGI MIPS 8000
>
> Operating System (example: Linux 2.0.26 ELF) : IRIX 6.5.5m
>
> PostgreSQL version (example: PostgreSQL-7.1): PostgreSQL-7.1
>
> Compiler used (example: gcc 2.8.0): MIPSPro 7.3

Not clear at this point if the differences in your results are due to
hardware, library version, or compiler version differences.

regards, tom lane

Tom Lane wrote:

> Luis Amigo <lamigo(at)atc(dot)unican(dot)es> writes:
> > again join and geometry(it also failed in postgres 7.1.3)
>
> The join discrepancy is probably an artifact of your local qsort()
> behaving slightly differently for equal keys than everyone else's.
> Curious that it only affects these few queries, though.
>
> Geometry differences in the low-order digits are par for the course.
> I wouldn't even stop to think about it, except that I see that you
> are already using a platform-specific geometry comparison file
> (geometry-irix.out). Some digging in the CVS logs and mail archives
> shows that that file was submitted by Pete Forman in Oct 2000, and
> he was using
>
> > Architecture (example: Intel Pentium) : SGI MIPS 8000
> >
> > Operating System (example: Linux 2.0.26 ELF) : IRIX 6.5.5m
> >
> > PostgreSQL version (example: PostgreSQL-7.1): PostgreSQL-7.1
> >
> > Compiler used (example: gcc 2.8.0): MIPSPro 7.3
>
> Not clear at this point if the differences in your results are due to
> hardware, library version, or compiler version differences.
>
> regards, tom lane

I've reviewed the results, join differences seem to be conceptual
differences, expected result gives higher value to NULL that 0
(personally I think 0 is bigger than NULL).
Geometry differences are architectural round up differences (I think
that MIPS 10000 and 12000 may have corrected previous errors or might
be a different point-of-view about rounding)

> regression test on irix 6.5.12 with MIPSpro Compilers: Version 7.3.1.2m
> (this platform is 8-r10000 ip25 processors, previous is 8 -r12000 ip35 processors)
>
> =======================
> 2 of 79 tests failed.
> =======================
> again join and geometry(it also failed in postgres 7.1.3)

Got both reports. Counts as good from my pov...

Thanks!

- Thomas

Thomas Lockhart wrote:

> > regression test on irix 6.5.12 with MIPSpro Compilers: Version 7.3.1.2m
> > (this platform is 8-r10000 ip25 processors, previous is 8 -r12000 ip35 processors)
> >
> > =======================
> > 2 of 79 tests failed.
> > =======================
> > again join and geometry(it also failed in postgres 7.1.3)
>
> Got both reports. Counts as good from my pov...
>
> Thanks!
>
> - Thomas

I also count them as good but I think that someone may change expected, cause two
platforms with different OS, architecture and compilers are giving same result.

Tom Lane wrote:

> Luis Amigo <lamigo(at)atc(dot)unican(dot)es> writes:
> > again join and geometry(it also failed in postgres 7.1.3)
>
> The join discrepancy is probably an artifact of your local qsort()
> behaving slightly differently for equal keys than everyone else's.
> Curious that it only affects these few queries, though.
>
> Geometry differences in the low-order digits are par for the course.
> I wouldn't even stop to think about it, except that I see that you
> are already using a platform-specific geometry comparison file
> (geometry-irix.out). Some digging in the CVS logs and mail archives
> shows that that file was submitted by Pete Forman in Oct 2000, and
> he was using
>
> > Architecture (example: Intel Pentium) : SGI MIPS 8000
> >
> > Operating System (example: Linux 2.0.26 ELF) : IRIX 6.5.5m
> >
> > PostgreSQL version (example: PostgreSQL-7.1): PostgreSQL-7.1
> >
> > Compiler used (example: gcc 2.8.0): MIPSPro 7.3
>
> Not clear at this point if the differences in your results are due to
> hardware, library version, or compiler version differences.
>
> regards, tom lane

I've been searching for info that could explain round-up difference in
geometry.
I believe i've found a reasonable explanation, there is a architecture
disroupt between old MIPS3 FPUs
and newer MIPS4 FPUs.(so I'm almost sure that is the explanation).
I would like to know if is there anyone else running on IRIX, so we can
discuss these and other results
from another point of view.
Thanks for all your heavy working.
best wishes.

Luis Amigo <lamigo(at)atc(dot)unican(dot)es> writes:
> I've been searching for info that could explain round-up difference in
> geometry.
> I believe i've found a reasonable explanation, there is a architecture
> disroupt between old MIPS3 FPUs
> and newer MIPS4 FPUs.(so I'm almost sure that is the explanation).
> I would like to know if is there anyone else running on IRIX, so we can
> discuss these and other results from another point of view.

I sent mail earlier to Pete Forman, who submitted the existing
geometry-irix comparison file. He hasn't responded yet.

If Pete's lost interest then I'd be willing to adopt your results as
the standard geometry-irix file. If he's still interested then we'd
need to figure out a way for the resultmap mechanism to distinguish
older and newer MIPS hardware in order to accommodate two sets of
IRIX geometry results. Got any idea how to do that? (Does config.guess
produce any relevant info?)

regards, tom lane

Tom Lane wrote:

> Luis Amigo <lamigo(at)atc(dot)unican(dot)es> writes:
>
> > I believe i've found a reasonable explanation, there is a architecture
> > disroupt between old MIPS3 FPUs
> > and newer MIPS4 FPUs.(so I'm almost sure that is the explanation).
>
> If Pete's lost interest then I'd be willing to adopt your results as
> the standard geometry-irix file. If he's still interested then we'd
> need to figure out a way for the resultmap mechanism to distinguish
> older and newer MIPS hardware in order to accommodate two sets of
> IRIX geometry results. Got any idea how to do that? (Does config.guess
> produce any relevant info?)
>
> regards, tom lane

First I have to apologize, I said MIPS3 and MIPS4 architecture, MIPS are
proccesor instructions set no architecture, and r8000 CPUs have MIPS4
instructions set.
I should have said old 8010 FPUs and newer 10010 and 12010 FPUs.
I think there are only three possible reasons in differences:
1.- FPUs architecture.
2.- compiler specific optimization( It's only possible if Pete turned on
extensive optimization for 8000), because we are compiling with
full-compatibility options -rx directives optimize cache and memory use but
does not affect proccessors.)
3.-If regress is sending binary data to disk and later retrieving the data
and writing output files, there "might" be rounding up differences between
what was written and readed.

I still believe this difference is made by FPUs
config.guess only says mips-sgi-irix6.5
I think we can make two results choosing FPUs from hinv
but we don´t have another r8000 to test Pete's results nor another r10000 or
12000 to test our results.
I would try to test in our 4 r10000 IP27 to be sure that our results are
right.

regards
Luis Amigo

Luis Amigo writes:

> I still believe this difference is made by FPUs
> config.guess only says mips-sgi-irix6.5

If your uname -m gives any clue about the processor type we might want to
create a patch for config.guess.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut wrote:

> Luis Amigo writes:
>
> > I still believe this difference is made by FPUs
> > config.guess only says mips-sgi-irix6.5
>
> If your uname -m gives any clue about the processor type we might want to
> create a patch for config.guess.
>
> --
> Peter Eisentraut peter_e(at)gmx(dot)net

uname -m returns IP25 what is SGI platform, it's about cache sizes and
internal net issues, I'm not sure that would work, I think it's more
reliable to do:
congrio 39% hinv -t cpu
CPU: MIPS R10000 Processor Chip Revision: 2.5
CPU: MIPS R10000 Processor Chip Revision: 2.5
CPU: MIPS R10000 Processor Chip Revision: 2.5
CPU: MIPS R10000 Processor Chip Revision: 2.5
CPU: MIPS R10000 Processor Chip Revision: 2.6
CPU: MIPS R10000 Processor Chip Revision: 2.6
CPU: MIPS R10000 Processor Chip Revision: 2.6
CPU: MIPS R10000 Processor Chip Revision: 2.6
or
congrio 40% hinv -t fpu
FPU: MIPS R10010 Floating Point Chip Revision: 2.5
FPU: MIPS R10010 Floating Point Chip Revision: 2.5
FPU: MIPS R10010 Floating Point Chip Revision: 2.5
FPU: MIPS R10010 Floating Point Chip Revision: 2.5
FPU: MIPS R10010 Floating Point Chip Revision: 2.6
FPU: MIPS R10010 Floating Point Chip Revision: 2.6
FPU: MIPS R10010 Floating Point Chip Revision: 2.6
FPU: MIPS R10010 Floating Point Chip Revision: 2.6
as you wish
best regards

Luis Amigo <lamigo(at)atc(dot)unican(dot)es> writes:
> uname -m returns IP25 what is SGI platform, it's about cache sizes and
> internal net issues, I'm not sure that would work, I think it's more
> reliable to do:
> congrio 39% hinv -t cpu
> congrio 40% hinv -t fpu

I'm not eager to add such a platform-dependent test to the resultmap
code, especially not when the issue is just the geometry results; we
already know that the long-term answer there must be to display fewer
digits in the test output. Also, we don't know what this program will
report for older MIPS boxes anyway. (Pete Forman hasn't responded to my
ping, so I'm inclined to assume that he's not actively tracking Postgres
development anymore; we can't expect help from him to check it on the
older boxes.)

I'd be willing to just commit the newer-hardware IRIX results as
geometry-irix for 7.2. Somebody's got to put up with a discrepancy,
and it may as well be the older boxes.

Comments?

regards, tom lane

Tom Lane wrote:

> Luis Amigo <lamigo(at)atc(dot)unican(dot)es> writes:
> > uname -m returns IP25 what is SGI platform, it's about cache sizes and
> > internal net issues, I'm not sure that would work, I think it's more
> > reliable to do:
> > congrio 39% hinv -t cpu
> > congrio 40% hinv -t fpu
>
> I'm not eager to add such a platform-dependent test to the resultmap
> code, especially not when the issue is just the geometry results; we
> already know that the long-term answer there must be to display fewer
> digits in the test output. Also, we don't know what this program will
> report for older MIPS boxes anyway. (Pete Forman hasn't responded to my
> ping, so I'm inclined to assume that he's not actively tracking Postgres
> development anymore; we can't expect help from him to check it on the
> older boxes.)
>
> I'd be willing to just commit the newer-hardware IRIX results as
> geometry-irix for 7.2. Somebody's got to put up with a discrepancy,
> and it may as well be the older boxes.
>
> Comments?
>
> regards, tom lane

I'm completely with you, I don´t think that would be useful to mantain such
firmware dependecies, but I think that it might be useful to document this
and problems with gcc, now we all remember this issue, but in two months
all will be forgotten.
We had here a lot of trouble installing our first 7.1.3 postgres because it
wasn´t documented that gcc simply doesn´t run. I swear that when I had time
I will try to compile with gcc and new libgcc links to try to fix this
problem.

> I almost forget:

best wishes and regards

Luis Amigo <lamigo(at)atc(dot)unican(dot)es> writes:
> I'm completely with you, I dont think that would be useful to mantain such
> firmware dependecies, but I think that it might be useful to document this
> and problems with gcc, now we all remember this issue, but in two months
> all will be forgotten.
> We had here a lot of trouble installing our first 7.1.3 postgres because it
> wasnt documented that gcc simply doesnt run. I swear that when I had time
> I will try to compile with gcc and new libgcc links to try to fix this
> problem.

Would you like to make up a FAQ_IRIX document similar to the ones we
have for some other platforms (see, eg, doc/FAQ_HPUX)? It doesn't need
to be long or fancy, just cover the things you wish you'd known sooner.

regards, tom lane