Re: NetBSD/Alpha and rkirkpat's patch [was Re: regress failed tests.. SERIOUS?] - Mailing list pgsql-bugs

On Saft, 30 Dec 2000, Thomas T. Thai wrote:

i grabbed the CVS ball last night and tried to build it. i'm attaching a
patch that made it possible to build -current on NetBSD/Alpha
1.5.1_ALPHA. i would appreciate it if you have cvs write access to
integrate my patch back into the tree.

after install, i did the regression test and it failed in the same way
that 7.0.3+rkirkpat.patch did as described below (copy of my last post).

> Date: Sat, 30 Dec 2000 01:42:11 -0600 (CST)
> From: Thomas T. Thai <tom@minnesota.com>
> To: Tom Lane <tgl@sss.pgh.pa.us>
> Cc: pgsql-bugs@postgresql.org, Brent Verner <brent@rcfile.org>,
>      Ryan Kirkpatrick <pgsql@rkirkpat.net>,
>      Adriaan Joubert <a.joubert@albourne.com>,
>      Arrigo Triulzi <arrigo@albourne.com>
> Subject: 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@sss.pgh.pa.us>
> > To: Thomas T. Thai <tom@minnesota.com>
> > Cc: PostgreSQL General <pgsql-general@postgresql.org>
> > Subject: Re: regress failed tests.. SERIOUS?
> >
> > "Thomas T. Thai" <tom@minnesota.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.
>