Subject: R-tree problem (the continuing story)

From: "Schenkelaars.V.F" <[email-masked]>
Date: Wed, 24 Jun 92 12:41:25 MET DST

Dear Mike,

> what happens is that your intersection routine returns NULL if two boxes
> don't intersect.  the quadratic-cost split algorithm from guttman's paper,
> as i implemented it for postgres, computes the sizes of the union and
> intersection of the n-dimensional boxes in order to choose an optimal
> node split.  Size3Box() got passed the null pointer from the intersect
> routine.
> 
> i'll fix the split code to check for this condition before calling
> the intersect procedure.  for the time being, the change described above
> will solve your problem.  i successfully ran your test program on my
> system this afternoon, with these modifications.
> 
> incidentally, i'm pleased to see you folks are extending the access method
> classes like this.  your code was clean, and you uncovered a genuine bug.
> let me know if you have further problems -- response times should get
> shorter, now that summer is here.
> 					mike olson
> 					project sequoia 2000
> 					uc berkeley
> 					[email-masked]

This is very nice, but there is still a problem left. I've already
asked this before but I didn't get any answers. When I define a index
first and than add all the tuples, everything is going fine. But when
I first add all the tuples and create an index afterwards, the size of the
postgres backend grows extremely and finally terminates with a core dump.
What is going wrong. 

About adding an new access class, how do I start with doing so? I have to
implement an R-tree based index structure so I "only" have to change
your R-tree code somewhat. A brute solution would be changing the R-tree 
code and recompile Postgres. Howerver I am wondering if there is not
an elegant solution for it. Which files are dealing with the R-tree?

Regards
 
     ____________________
 \  / . _   _  _   _  |
  \/ ( ( \ (_ (-' ( \ |

--------------------------------------------------------------------------------
Vincent F. Schenkelaars				|
Company: FEL-TNO                                | Private:
Email  : [email-masked]	|
address: Oude Waalsdorperweg 63			| Groenhovenstraat 12
         Postbus 96864				|
         2509 JG  Den Haag			| 2311 BT  Leiden
         The Netherlands			| The Netherlands
Phone  : Holland 070-3264221			| Holland 071-125576
Fax    : Holland 070-3280961			|
--------------------------------------------------------------------------------
We apologize for the inconvenience.

---

From: postarch (Postgres Mailing Archive)
Date: Wed, 24 Jun 92 08:38:44 PDT

> postgres backend grows extremely and finally terminates with a core dump.

Vincent,

As I understand it, Mike is working on your latest but report.  We, in general,
don't respond to bug reports unless we have fixed the bug.  The bugs account
is set up to send an acknowledgement to incoming messages so that
people know we are receiving them (this doesn't apply to messages sent
to the mailing list).  If you get an acknowledgement, then you can be sure
that we will be looking at the problem.  You will have to be patient with us,
as we are extremely busy at present.

Jeff Meredith
[email-masked]