Re: Problems with genetic optimizer

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