results of regression tests: NetBSD/i386 v1.3

Started by Brook Milliganalmost 28 years ago5 messages
#1Brook Milligan
brook@trillium.NMSU.Edu

Now that I have run the regression tests for 6.3 on a NetBSD/i386 v1.3
box I am wondering what to do with them. Should they be used as a
source for bug fixes before the next release? If so, how should they
be used? By me only, or should I post them somewhere for others to
review?

Cheers,
Brook

#2Thomas G. Lockhart
lockhart@alumni.caltech.edu
In reply to: Brook Milligan (#1)
Re: [HACKERS] results of regression tests: NetBSD/i386 v1.3

Now that I have run the regression tests for 6.3 on a NetBSD/i386 v1.3
box I am wondering what to do with them. Should they be used as a
source for bug fixes before the next release? If so, how should they
be used? By me only, or should I post them somewhere for others to
review?

Do they illustrate platform-specific bugs? If not, then we all can use
our own platforms for these examples.

If the differences are platform-specific, but expected, then perhaps Marc
would like to get these for his "OS-specific" regression test
comparisons??

- Tom

#3Brook Milligan
brook@trillium.NMSU.Edu
In reply to: Thomas G. Lockhart (#2)
Re: [HACKERS] results of regression tests: NetBSD/i386 v1.3

Do they illustrate platform-specific bugs? If not, then we all can use
our own platforms for these examples.

I'm not sure how I would recognize platform-specific bugs since I only
have one platform. In the past I've ignored them, but I just thought
this might be the time to point out problems that need attention in
case they are something unusual.

Diffs from the expected output yield things like:

- ERROR:  pg_atoi: error reading "100000": Math result not representable
+ ERROR:  pg_atoi: error reading "100000": Result too large
- ERROR:  Bad float8 input format '10e-400'
+ ERROR:  Bad float8 input format '-10e-400'
+ ERROR:  check_fkeys2_pkey_exist: tuple references non-existing key in pkeys
+ ERROR:  check_fkeys_pkey_exist: tuple references non-existing key in pkeys
- NOTICE:  check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted
+ ERROR:  check_fkeys2_fkey_restrict: tuple referenced in fkeys

- ERROR: Cannot insert a duplicate key into a unique index

- NOTICE: Non-functional update, only first update is performed

If these are general diffs, I'll ignore them; otherwise, I'll be glad
to give more specific information.

Cheers,
Brook

#4Thomas G. Lockhart
lockhart@alumni.caltech.edu
In reply to: Brook Milligan (#1)
Re: [HACKERS] results of regression tests: NetBSD/i386 v1.3

Do they illustrate platform-specific bugs? If not, then we all can use
our own platforms for these examples.

I'm not sure how I would recognize platform-specific bugs since I only
have one platform. In the past I've ignored them, but I just thought
this might be the time to point out problems that need attention in
case they are something unusual.

Diffs from the expected output yield things like:
<snip>

These are typical platform-specific differences, and are expected. The last few
examples are from the trigger tests, which are going to be revisited before v6.3
release by Vadim (I hope :).

- Tom

#5Vadim B. Mikheev
vadim@sable.krasnoyarsk.su
In reply to: Brook Milligan (#1)
Re: [HACKERS] results of regression tests: NetBSD/i386 v1.3

Thomas G. Lockhart wrote:

Do they illustrate platform-specific bugs? If not, then we all can use
our own platforms for these examples.

I'm not sure how I would recognize platform-specific bugs since I only
have one platform. In the past I've ignored them, but I just thought
this might be the time to point out problems that need attention in
case they are something unusual.

Diffs from the expected output yield things like:
<snip>

These are typical platform-specific differences, and are expected. The last few
examples are from the trigger tests, which are going to be revisited before v6.3
release by Vadim (I hope :).

Results are the same as in 6.2.1 expected. So, I just put 6.2.1 expected
into 6.3 expected (with WARN: --> ERROR: translation). Should be ok now.
Let's know if not.

Vadim