Peter Keller <peter.keller@bvv.bayern.de> writes:
> No, I'm sorry, but there is no core file.
You're probably running one of those setups where the postmaster is
started with a ulimit setting that prevents core dumps. You might
want to look into changing that for future debugging purposes.
> query: select * from box_tmp where ebre &&
> ('(470758.555,354028.145),(470758.525
> ,354028.115)'::box);
> ProcessQuery
> /opt/local/DWH/bin/postmaster: reaping dead processes...
> /opt/local/DWH/bin/postmaster: CleanupProc: pid 679 exited with status
> 11
Now that I think about it, are there any NULL entries in box_tmp.ebre?
The box_overlap function, like practically all of the geometric
operators :-(, doesn't defend itself against NULL inputs in 7.0 and
earlier releases. This is fixed for 7.1 but not in a way that could
readily be back-patched into 7.0.*. If there are just specific
operators you need to use with NULL data, you could patch them yourself
in src/backend/utils/adt/geo_ops.c; for instance box_overlap would need
to start out with something like
if (box1 == NULL || box2 == NULL)
return false;
Alternatively, write your queries to avoid invoking && on a NULL, eg
select * from box_tbl where
case when ebre is not null then
ebre && '(470758.555,354028.145),(470758.525,354028.115)'
else false end;
This last is not only ugly but non-indexable, so it's only useful as
a very short-term hack...
regards, tom lane
