Re: [HACKERS] Core dump in regression tests.

> > > 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.

Yes, very strange.

>
> - 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.

I believe David Hartwig has claimed this problem, and knows the cause.
He posted something recently.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)