Re: [HACKERS] Backend terminated abnormally

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "nicks(dot)emails" <nicks(dot)emails(at)ic24(dot)net>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Backend terminated abnormally
Date: 1999-11-02 05:19:44
Message-ID: 10588.941519984@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-11-02 05:31:04 Re: [HACKERS] sort on huge table
Previous Message Victoria W. 1999-11-02 05:09:42 unsubscribe