Thread: results of regression tests: NetBSD/i386 v1.3

results of regression tests: NetBSD/i386 v1.3

From
Brook Milligan
Date:
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

Re: [HACKERS] results of regression tests: NetBSD/i386 v1.3

From
"Thomas G. Lockhart"
Date:
> 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


Re: [HACKERS] results of regression tests: NetBSD/i386 v1.3

From
Brook Milligan
Date:
   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

Re: [HACKERS] results of regression tests: NetBSD/i386 v1.3

From
"Thomas G. Lockhart"
Date:
>    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


Re: [HACKERS] results of regression tests: NetBSD/i386 v1.3

From
"Vadim B. Mikheev"
Date:
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