Re: gist index build produces corrupt result on - Mailing list pgsql-general

From Eric Davies
Subject Re: gist index build produces corrupt result on
Date
Msg-id 5.2.1.1.0.20040304124638.011502d0@marilyn.barrodale.com
Whole thread Raw
In response to Re: gist index build produces corrupt result on first access to table.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general

At 10:28 PM 3/3/2004, Tom Lane wrote:
Eric Davies <eric@barrodale.com> writes:
> We've looked at the contrib/cube code, but it's also a variable length
> parameter, and it uses a very different parameter passing mechanism.

Different how?  I have a hard-to-pin-down intuition that your problem is

the parameter passing mechanism used by Postgis (and our 5D box) is to
pass a FunctionCallInfoData structure, via a PG_FUNCTION_ARGS macro.
The Postgis penalty function starts with:
/*
** The GiST Penalty method for boxes
** As in the R-tree paper, we use change in area as our penalty metric
*/
PG_FUNCTION_INFO_V1(gbox_penalty);
Datum gbox_penalty(PG_FUNCTION_ARGS)
{
        GISTENTRY  *origentry = (GISTENTRY *) PG_GETARG_POINTER(0);

the cube code appears to pass each argument separately, as one would normally do with a
C program. Ie, the g_cube_penalty function starts with:
/*
** The GiST Penalty method for boxes
** As in the R-tree paper, we use change in area as our penalty metric
*/
float *
g_cube_penalty(GISTENTRY *origentry, GISTENTRY *newentry, float *result)
{
        NDBOX      *ud;
        double          tmp1,

Again, the postgis code seems to work fine with GiST indexes, so I would rule out the argument passing mechanism as being of influence.


closely associated with this issue, but without details it's impossible
to say more.  IIRC there were once assumptions in rtree and/or gist
about the indexable datatype being pass-by-ref and/or varlena, and I'm
not sure how much of that has been fixed.

This seems a bit far afield for pgsql-general, however.  I would
suggest offering more details on -hackers.  If you could post your code
for people to play with, you'd likely get answers pretty quickly.

I figured likewise, but the etiquete for the postgresql.org group required
I try the more general group first. :-).
I'll give that a shot now.

                        regards, tom lane

**********************************************
Eric Davies, M.Sc.
Barrodale Computing Services Ltd.
Tel: (250) 472-4372 Fax: (250) 472-4373
Web: http://www.barrodale.com
Email: eric@barrodale.com
**********************************************
Mailing Address:
P.O. Box 3075 STN CSC
Victoria BC Canada V8W 3W2

Shipping Address:
Hut R, McKenzie Avenue
University of Victoria
Victoria BC Canada V8W 3W2
**********************************************


pgsql-general by date:

Previous
From: "Uwe C. Schroeder"
Date:
Subject: Re: REFERENCES error message complaint, suggestion
Next
From: Greg Stark
Date:
Subject: Re: REFERENCES error message complaint, suggestion