Обсуждение: 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
"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 triedselect 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
> "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
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
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
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
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
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 seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================