Re: [HACKERS] Core dump in regression tests. - Mailing list pgsql-hackers

> > Uh, no, Linux/i686 is showing trouble too, but not in the initdb
> > stage. The Sparc platforms will be more sensitive to byte alignment
> > problems, especially within C structures, so this may be
> > illustrating a cross-platform problem more clearly.
> > There is a repeatable indexing and (perhaps) caching problem I see
> > in the regression tests. Annoyingly, the problems get slightly worse
> > at the moment when compiling with -O0.
> OK, here is my regression output.  Do you see anything strange in
> there?

Well, yes, just not as strange as my tests :) You don't have int8
enabled, and if your compiler and libc allow it I'd like to get that
going. But that isn't a problem.

You have a core dump from the "having" test. Is that a known problem
with someone working on a solution? The test worked on my ~month-old
development tree (I could probably figure out the vintage of that tree
to more precision if it would be helpful), so something has happened in
the meantime.

I suspect that (possibly) more than one thing is going on, since there
were some changes directly related to removing the oddball OID types as
well as perhaps cleanup changes made while traversing the code.
Something may have crept in there.

If these tests are the only ones showing problems on your machine, then
consider yourself lucky. I've got several more failures, including the
one where I can't create indices on a table until after terminating and
restarting the session. The Sparc contingent sees more problems than I,
but they are on a Risc machine so will see alignment problems if they
are present.

                      - Tom

> ======   int8   ======
> --- expected/int8.out   Sun Aug 23 11:09:38 1998
> +++ results/int8.out    Tue Sep  1 23:40:10 1998
> @@ -6,110 +6,110 @@
>  QUERY: INSERT INTO INT8_TBL VALUES('4567890123456789','-4567890123456789');
>  QUERY: SELECT * FROM INT8_TBL;
>                q1|               q2
> -----------------+-----------------
> +----------+-----------
>               123|              456
> -             123| 4567890123456789
> -4567890123456789|              123
> -4567890123456789| 4567890123456789
> -4567890123456789|-4567890123456789
> +       123| 2147483647
> +2147483647|        123
> +2147483647| 2147483647
> +2147483647|-2147483648
>  (5 rows)
> ======   select_having   ======
> --- expected/select_having.out  Sat Aug 29 00:10:03 1998
> +++ results/select_having.out   Tue Sep  1 23:41:51 1998
> @@ -11,27 +11,6 @@
>  QUERY: INSERT INTO test_having VALUES (9, 4, 'CCCC', 'j');
>  QUERY: SELECT max(a) FROM test_having
>         GROUP BY lower(c) HAVING count(*) > 2 OR min(b) = 3;
<snip>
> -QUERY: DROP TABLE test_having;
> +pqReadData() -- backend closed the channel unexpectedly.
> +       This probably means the backend terminated abnormally before or while processing the request.
> +We have lost the connection to the backend, so further processing is impossible.  Terminating.

OK, this test did not fail on my development tree from a month ago. What
changed? I'm seeing it fail here also.

                        - Tom