Re: BUG #1015: Got a signal 11 while trying to create a temp table - Mailing list pgsql-bugs

From aarjan langereis
Subject Re: BUG #1015: Got a signal 11 while trying to create a temp table
Date
Msg-id 055101c3c60b$8f011aa0$6800a8c0@Aarjan
Whole thread Raw
In response to BUG #1015: Got a signal 11 while trying to create a temp table  ("PostgreSQL Bugs List" <pgsql-bugs@postgresql.org>)
Responses Re: BUG #1015: Got a signal 11 while trying to create a temp table
List pgsql-bugs
How do I get a "debugger backtrace" ?

Selecting all data from the tables involved, does that also include a 'coun=
t(*)', if so, they work:

stats=3D# select count(*) from blocks;
  count
---------
 3194409
(1 row)

stats=3D# select count(*) from hosts;
 count
-------
   205
(1 row)

stats=3D#

Yours,

Aarjan

----- Original Message -----=20
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: <A.j.langereis@chello.nl>
Cc: "PostgreSQL Bugs List" <pgsql-bugs@postgresql.org>
Sent: Friday, December 19, 2003 4:41 AM
Subject: Re: [BUGS] BUG #1015: Got a signal 11 while trying to create a tem=
p table=20


> "PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
> > I tried to create a temp table and got my back-end restarting because o=
f a signal 11.
>=20
> Hmm.  Can you get a debugger backtrace from the core dump?
>=20
> > It seems to me, and please correct me if I=E2?Tm wrong, that there is a=
 limit to the size that a join can handle.
>=20
> No (and certainly not on a measly 3-million-row case).  This could be a
> data corruption problem, or something more subtle, but it's not that.
>=20
> One way of testing the data-corruption theory is to see if you can
> select all the data from the tables involved, without any join.
>=20
> regards, tom lane
>

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Urgent: Key constraints behaving weirdly
Next
From: Marek Lewczuk
Date:
Subject: CASE in where statement. BUG ??