NetBSD/Alpha and rkirkpat's patch [was Re: regress failed tests.. SERIOUS?]

On Fri, 29 Dec 2000, Tom Lane wrote:

> Date: Fri, 29 Dec 2000 23:20:58 -0500
> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> To: Thomas T. Thai <tom(at)minnesota(dot)com>
> Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
> Subject: Re: regress failed tests.. SERIOUS?
>
> "Thomas T. Thai" <tom(at)minnesota(dot)com> writes:
> > PLEASE NOTE: I'm brand new to PostgreSQL as of today. I've just moved from
> > MySQL because it's not stable on NetBSD/Alpha. I don't know enough about
> > pgsql to see if these failed test would make it unstable for production.
>
> Postgres 7.0.* will not work very well on Alpha unless you apply Ryan
> Kirkpatrick's patch set (I forget the URL offhand, but dig around in our
> archives and you'll find it). 7.1 should be a lot better. If you'd
> like to help out testing 7.1, please grab current sources from the CVS
> server, or grab a snapshot tarball dated tomorrow or later.

i did just that. i applied the patch that is available at:

http://www.rkirkpat.net/software/#linux-alpha

to my NetBSD/Alpha 1.5.1_ALPHA PostgreSQL 7.0.3 package. compiled with out
errors. some warnings about casting wrong pointers types etc, but they
seem harmless.

even though Kirkpatrick said his patch was for the Linux/Alpha, most of
his modifications weren't so Linux centric as it was Alpha
centric. consequently, the patch worked out well for NetBSD/Alpha as well.

with the above patch, the regression now only failed on 2 tests:

$ grep failed regress.out
float8 .. failed
timestamp .. failed
horology .. failed

float8 did pass, just diff format of the error message. 'timestamp' and
'horology' not only failed but caused many 'Fatal User Traps' logged in
newsyslog '/var/log/messages':

<cut>
Dec 30 01:22:33 ns01 /netbsd: fatal user trap:
Dec 30 01:22:33 ns01 /netbsd:
Dec 30 01:22:33 ns01 /netbsd: trap entry = 0x1 (arithmetic trap)
Dec 30 01:22:33 ns01 /netbsd: a0 = 0x2
Dec 30 01:22:33 ns01 /netbsd: a1 = 0x40000000000
Dec 30 01:22:33 ns01 /netbsd: a2 = 0xffffffffffffffff
Dec 30 01:22:33 ns01 /netbsd: pc = 0x1201449f8
Dec 30 01:22:33 ns01 /netbsd: ra = 0x120029ca4
Dec 30 01:22:33 ns01 /netbsd: curproc = 0xfffffc0023bb6c98
Dec 30 01:22:33 ns01 /netbsd: pid = 1705, comm = postgres
</cut>

the 'fatal user trap' errors seem to happen whenever there is a query
that resulted in SQL error message "ERROR: floating point exception! The
last floating point operation either exceeded legal ranges or was a
divide by zero."

for the 'strings' test, it passed but this line in 'strings.sql'

SELECT CAST(f1 AS char(10)) AS "char(text)" FROM TEXT_TBL;

caused these output on the console:

<cut>
pid 1684 (postgres): unaligned access: va=0x1a007dd25 pc=0x12014bd10
ra=0x12014b
cac op=ldl
pid 1684 (postgres): unaligned access: va=0x1a007dd26 pc=0x12014bd10
ra=0x12014b
cac op=ldl
pid 1684 (postgres): unaligned access: va=0x1a007dd27 pc=0x12014bd10
ra=0x12014b
cac op=ldl
pid 1684 (postgres): unaligned access: va=0x1a007dced pc=0x12014bd10
ra=0x12014b
ce4 op=ldl
pid 1684 (postgres): unaligned access: va=0x1a007dcee pc=0x12014bd10
ra=0x12014b
ce4 op=ldl
pid 1684 (postgres): unaligned access: va=0x1a007dcef pc=0x12014bd10
ra=0x12014b
ce4 op=ldl
pid 1684 (postgres): unaligned access: va=0x1a007dcf1 pc=0x12014bd10
ra=0x12014b
ce4 op=ldl
pid 1684 (postgres): unaligned access: va=0x1a007dcf2 pc=0x12014bd10
ra=0x12014b
ce4 op=ldl
pid 1684 (postgres): unaligned access: va=0x1a007dcf3 pc=0x12014bd10
ra=0x12014b
ce4 op=ldl
pid 1684 (postgres): unaligned access: va=0x1a007dcf5 pc=0x12014bd10
ra=0x12014b
ce4 op=ldl
</cut>

(but nothing in '/var/log/messages').

i'm attaching the regression.diffs file. in addition, i'm going to move
this thread to pgsql-bugs instead of pgsql-general.