"nicks.emails" <nicks.emails@ic24.net> writes:
> select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;

> when I try to execute this intersection on the tables that are in the
> regression queries the following message is printed to the screen,

I'm confused --- I don't see any table named LSEG_TBL1 in the standard
regression tests.  Are you sure you didn't create that one yourself?

I tried
	select l.s # p.s from LSEG_TBL l, LSEG_TBL p;
using the table that is there, and it gave me answers (I have no idea
if they're right though ;-)).

			regards, tom lane

Mon, 01 Nov 1999 18:17:16 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Backend terminated abnormally 
> "nicks.emails" wrote:
> 
> Hello,
> 
> I not sure if I have got the right person for this but if you could
> help me it would be extremely helpful;
> 
> The problem is with the following query,
> 
> select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;

Duplicated with PostgreSQL 6.5.2 on RedHat 6.0, egcs 1.1.2.

Will get more details as I have them.

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Mon, 01 Nov 1999 20:07:20 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Backend terminated abnormally
Lamar Owen <lamar.owen@wgcr.org> writes:
>> The problem is with the following query,
>> select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;

> Duplicated with PostgreSQL 6.5.2 on RedHat 6.0, egcs 1.1.2.

Hmm, does everyone but me have a table named LSEG_TBL1 in the
regress tests?  I've grepped both current and REL6_5 and I'll
be durned if I can find any use of that name.  I'd look into it
if I had a reproducible test case...

			regards, tom lane

Mon, 01 Nov 1999 22:18:31 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Backend terminated abnormally 
On Mon, 01 Nov 1999, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> >> The problem is with the following query,
> >> select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;
> 
> > Duplicated with PostgreSQL 6.5.2 on RedHat 6.0, egcs 1.1.2.
> 
> Hmm, does everyone but me have a table named LSEG_TBL1 in the
> regress tests?  I've grepped both current and REL6_5 and I'll
> be durned if I can find any use of that name.  I'd look into it
> if I had a reproducible test case...
> 
> 			regards, tom lane

Oh, sorry, Tom.  SELECT * INTO TABLE LSEG_TBL1 FROM LSEG_TBL; first.

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Mon, 1 Nov 1999 22:46:20 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Backend terminated abnormally
Lamar Owen <lamar.owen@wgcr.org> writes:
> On Mon, 01 Nov 1999, Tom Lane wrote:
>> Hmm, does everyone but me have a table named LSEG_TBL1 in the
>> regress tests?  I've grepped both current and REL6_5 and I'll
>> be durned if I can find any use of that name.  I'd look into it
>> if I had a reproducible test case...

> Oh, sorry, Tom.  SELECT * INTO TABLE LSEG_TBL1 FROM LSEG_TBL; first.

Actually, the missing clue seems to be that it's cool on HPUX and
coredumps on Linux.  Bigendian vs. littleendian bug maybe?  I'm on
it...

			regards, tom lane

Mon, 01 Nov 1999 23:04:35 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Backend terminated abnormally 
I wrote:
> Actually, the missing clue seems to be that it's cool on HPUX and
> coredumps on Linux.  Bigendian vs. littleendian bug maybe?  I'm on
> it...

Well, isn't *this* special: it seems that memmove(dest, NULL, n)
doesn't cause a coredump on HPUX, it just silently does nothing.
Sheesh.  I hardly ever use memmove, or I would've found this out
before (and complained about it!).


Anyway, the answer to the original complaint is that geo_ops.c
is brimful of operators that think they can return a NULL pointer
and it'll be interpreted as returning an SQL NULL.  They are
sadly misinformed.  In the present state of fmgr() there isn't
any way for a binary operator to return NULL when its operands
are not null.  Another reason we gotta redo the fmgr interface.

Nick, I'm afraid '#' is pretty seriously broken: it'll coredump
whenever presented non-intersecting segments, unless you are able
to recompile the system so that dereferencing a NULL pointer is
not a fatal error.  Several of the other geometric operators have
similar problems.  AFAICS there is not much that can be done to
patch around this; a proper fix will require some major changes
that we are planning for release 7.0.  Sorry the news isn't better.

			regards, tom lane

Tue, 02 Nov 1999 00:19:44 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Backend terminated abnormally 
Hello,

I not sure if I have got the right person for this but if you could help me it would be extremely helpful;

The problem is with the following query,

select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;

when I try to execute this intersection on the tables that are in the regression queries the following message is printed to the screen,

I created two tables with the exact lseg coordinates in both to see what happened and also with disimilar lseg points so that there was lines intersecting,
and recieved the same message

pgReadData() --backend closed the channel unexpectedly.

This problem 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.
 
Please could give me some pointers as to where I could look or if necesarry download any patches to fix it.

I am running Redhat 5.2 on an i486-pc-linux-gnu
version of postgres is 6.5.2
version of gcc is 2.7.2.3

Thank you in advance.

Nick O'Malley nicks.emails@ic24.net 









Hello,
 
I not sure if I have got the right person for this 
but if you could help me it would be extremely helpful;
 
The problem is with the following 
query,
 
select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 
p;
 
when I try to execute this intersection on the 
tables that are in the regression queries the following message is printed 
to the screen,
 
I created two tables with the exact lseg coordinates in both to see what 
happened and also with disimilar lseg points so that there was lines 
intersecting,
and recieved the same message
 
pgReadData() --backend closed the channel 
unexpectedly.
 
This problem 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.
 
Please could give me some pointers as to where I 
could look or if necesarry download any patches to fix it.
 
I am running Redhat 5.2 on an 
i486-pc-linux-gnu
version of postgres is 6.5.2
version of gcc is 2.7.2.3
 
Thank you in advance.
 
Nick O'Malley nicks.emails@ic24.net
Mon, 1 Nov 1999 22:18:34 -0800
"nicks.emails" <nicks.emails@ic24.net>
Backend terminated abnormally
On Tue, 2 Nov 1999, Tom Lane wrote:

> I wrote:
> > Actually, the missing clue seems to be that it's cool on HPUX and
> > coredumps on Linux.  Bigendian vs. littleendian bug maybe?  I'm on
> > it...
> 
> Well, isn't *this* special: it seems that memmove(dest, NULL, n)
> doesn't cause a coredump on HPUX, it just silently does nothing.
> Sheesh.  I hardly ever use memmove, or I would've found this out
> before (and complained about it!).

HP is notorious for this.  Pass a null pointer to its atoi() and it'll
return zero.  Same thing on IRIX64.  Do this on a *BSD or Linux machine
and it'll segfault.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Tue, 2 Nov 1999 06:24:26 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Backend terminated abnormally 