I tried to reply to you but that doesn't work. So I try it through here..
Yours,=20
Aarjan
----- Original Message -----=20
From: aarjan langereis=20
To: Tom Lane=20
Sent: Saturday, December 20, 2003 3:17 PM
Subject: Fw: [BUGS] BUG #1015: Got a signal 11 while trying to create a tem=
p table
Did you find time to read my email? I hope you will reply sone.
Yours,
Aarjan
----- Original Message -----=20
From: aarjan langereis=20
To: pgsql-bugs@postgresql.org=20
Sent: Friday, December 19, 2003 9:39 AM
Subject: Re: [BUGS] BUG #1015: Got a signal 11 while trying to create a tem=
p table
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
>
