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

From: "Thomas T(dot) Thai" <tom(at)minnesota(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org, Brent Verner <brent(at)rcfile(dot)org>, Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net>, Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>, Arrigo Triulzi <arrigo(at)albourne(dot)com>
Subject: Re: NetBSD/Alpha and rkirkpat's patch [was Re: regress failed tests.. SERIOUS?]
Date: 2000-12-30 23:08:49
Message-ID: Pine.NEB.4.21.0012301704170.11655-200000@ns01.minnesota.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

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(at)minnesota(dot)com>
> To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Cc: pgsql-bugs(at)postgresql(dot)org, Brent Verner <brent(at)rcfile(dot)org>,
> Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net>,
> Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>,
> Arrigo Triulzi <arrigo(at)albourne(dot)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(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.
>

Attachment Content-Type Size
pgsql-current.diff text/plain 3.4 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas T. Thai 2000-12-31 00:39:23 NetBSD/Alpha and PostgreSQL-current [was Re: NetBSD/Alpha and rkirkpat's patch]
Previous Message Lok Group of companies 2000-12-30 09:39:34 problems During installation of 7.0.3

Browse pgsql-general by date

  From Date Subject
Next Message Thomas T. Thai 2000-12-31 00:39:23 NetBSD/Alpha and PostgreSQL-current [was Re: NetBSD/Alpha and rkirkpat's patch]
Previous Message Andre Fortin 2000-12-30 21:14:36 How to identify the class of a record