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.

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@candle.pha.pa.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)