<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [postgis-devel] CLUSTER in 8.3</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>So I guess its probably the fix to 8.3.5<BR>
<BR>
#<BR>
<BR>
Fix GiST index corruption due to marking the wrong index entry "dead" after a deletion (Teodor)<BR>
<BR>
This would result in index searches failing to find rows they should have found.<BR>
<BR>
That introduced this seeming race condition.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Paul Ramsey<BR>
Sent: Fri 12/5/2008 3:01 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] CLUSTER in 8.3<BR>
<BR>
Works with btree.<BR>
<BR>
pramsey=# create table ttt as select * from counties;<BR>
SELECT<BR>
pramsey=# create index gid_bix on ttt (gid);<BR>
CREATE INDEX<BR>
pramsey=# select count(*) from ttt;<BR>
count<BR>
-------<BR>
3141<BR>
(1 row)<BR>
<BR>
pramsey=# cluster ttt using gid_bix;<BR>
CLUSTER<BR>
pramsey=# select count(*) from ttt;<BR>
count<BR>
-------<BR>
3141<BR>
(1 row)<BR>
<BR>
<BR>
On Fri, Dec 5, 2008 at 11:49 AM, Chris Hodgson <chodgson@refractions.net> wrote:<BR>
> Kevin Neufeld wrote:<BR>
>><BR>
>> Mark Cave-Ayland wrote:<BR>
>> > I think the GiST part is a red herring - there is no way that a "SELECT<BR>
>>><BR>
>>> COUNT(*) FROM foo" can use an index in PostgreSQL. My suspicion is that<BR>
>>> it's related to the use of ANALYZE/VACUUM/CLUSTER.<BR>
>>><BR>
>><BR>
>> Maybe. You're right that "SELECT ..." doesn't use the index, but the<BR>
>> CLUSTER physically reorders the table based on the index. If there is a<BR>
>> bizzare bug in our GiST implementation that produces an empty traversal list<BR>
>> some of the time, the table would be empty.<BR>
>><BR>
>> Never mind, I just saw Paul's post. This is good news for us in that it's<BR>
>> not related to our implementation of GiST ... but it still could be related<BR>
>> to PostgreSQL's implementation, no?<BR>
><BR>
> Well, can anyone replicate the problem by clustering on a non-gist index? If<BR>
> so, then we should really be able to just throw this problem at the Postgres<BR>
> Devs. I'd be surprised if this was the case though, I can't believe no-one<BR>
> else would have come across this yet...<BR>
><BR>
> Chris<BR>
> _______________________________________________<BR>
> postgis-devel mailing list<BR>
> postgis-devel@postgis.refractions.net<BR>
> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
><BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>