From: | Peter Tanski <ptanski(at)raditaz(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GiST seems to drop left-branch leaf tuples |
Date: | 2010-11-23 16:39:33 |
Message-ID: | 0B1250AB-55F8-4475-9A0B-982B567A923B@raditaz.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Picksplit() seems to be an exceptional case here: the first and last
numbers in entryvec are invalid so
entryvec->vector[entryvec->n - 1]
is invalid. All the other GiST code Picksplit() functions use the
same convention. For example, see the btree_gist picksplit function, at
http://doxygen.postgresql.org/btree__utils__num_8c-source.html#l00241
OffsetNumber i,
maxoff = entryvec->n - 1;
On Nov 23, 2010, at 10:22 AM, Alvaro Herrera wrote:
> Excerpts from Peter Tanski's message of mar nov 23 12:00:52 -0300
> 2010:
>
>> There are checks inside the Picksplit() function for the number of
>> entries:
>>
>> OffsetNumber maxoff = entryvec->n - 1;
>> int n_entries, j;
>> n_entries = Max(maxoff, 1) - 1;
>>
>> j = 0;
>> for (i = FirstOffsetNumber; i < maxoff; i = OffsetNumberNext(i)) {
>> FPrint* v = deserialize_fprint(entv[i].key);
>
> Isn't this off by one? Offset numbers are 1-based, so the maxoff
> computation is wrong.
>
> --
> Álvaro Herrera <alvherre(at)commandprompt(dot)com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Tanski | 2010-11-23 16:44:39 | Re: GiST seems to drop left-branch leaf tuples |
Previous Message | Tom Lane | 2010-11-23 16:37:42 | Re: knngist - 0.8 |