Re: [HACKERS] Backend terminated abnormally
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Backend terminated abnormally |
Дата | |
Msg-id | 10588.941519984@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Backend terminated abnormally (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Backend terminated abnormally
|
Список | 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
В списке pgsql-hackers по дате отправления: