[postgis-devel] Re: geometry stats

[strk]

m.cave-ayland wrote:
> Hi strk,
> 
> Yeah, box_overlap() is a routine from the internal PostgreSQL geometric
> functions (see src/backend/utils/adt/geo_ops.c). The current way it
> works is that a BOX3D is converted into a BOX and then box_overlap() is
> called. Yuck. The fix in the thread I mentioned before was that I wrote
> my own equivalent of the contains() operator and added it into PostGIS
> instead of calling the PostgreSQL contains/contained functions which
> just appeared to be plain broken.

http://homepages.zen.co.uk/zen9662/postgis/ Not Found.
Anyway, I got your point and added a pgbox_overlap() function inside
postgis_gist_72.c that makes the same computation as geometry_overlap().
Its seem to be working now.
I think you were right calling for a completely 'internal' handling
of the GiST, for now I just made a quick fix, but I'm sure we should
review the code and make some cleanups there...
 
> > I actually get a random segfault, isn't this a 
> > get_attstatslot bug, anyway ? 
> 
> This is in the estimation function, right? Can you narrow it down to a
> particular area at all, i.e. if you just have the function do nothing
> except call get_attstatslot(), free_attstatslot() and return the default
> selectivity, does it still crash? I think this would be a good test.

Nope, the segfault is there including or excluding elog() calls
by setting DEBUG_GEOMETRY_STATS to 1 (no segfault) or 2 (segfault).
It happens at the end of the analyze; command, right before the end
of the function, so it's like postgresql is faced with wild pointers.

If you want to take a look change this:
@@ -1432,5 +1432,5 @@
-#if 0 & DEBUG_GEOMETRY_STATS > 1
+#if DEBUG_GEOMETRY_STATS > 1

and set DEBUG_GEOMETRY_STATS to 2
 
Allocation here happens for the GEOM_STATS struct itself in the
stats->anl_context context. Other allocations are made in
the 'current' context but are not meant to leave after
the end of the function.

--strk;