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
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 |