Looks like this is a dup of #4479:
http://archives.postgresql.org/pgsql-bugs/2008-10/msg00094.php
---------- Forwarded message ----------
Date: Wed, 22 Oct 2008 19:11:51 -0300
From: [EMAIL PROTECTED]
To: Jeff Frost <[EMAIL PROTECTED]>
Subject: Stalled post to pgsql-bugs
Your message to pgsql-bugs has been delayed, and requires the approval
of the moderators, for the following reason(s):
The author ("Jeff Frost" <[EMAIL PROTECTED]>)
is not a member of any of the restrict_post groups.
If you do not wish the message to be posted, or have other concerns,
please send a message to the list owners at the following address:
[EMAIL PROTECTED]--- Begin Message ---
The following bug has been logged online:
Bug reference: 4491
Logged by: Jeff Frost
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: Fedora 9/Gentoo/Mac OS X
Description: regression in gist indexes
Details:
It seems that 8.3.4 has a regression in the updating of gist indexes. After
updating an indexed column in a row with a postgis gist index, the row is no
longer found in an index scan. I have verified that this works on 8.2.7,
8.3.0, 8.3.1 and 8.3.3 but not 8.3.4.
Verified this is a problem on Fedora 9/Gentoo/Mac OS X.
You can see the test case here:
https://gist.github.com/d6c9b183196717d73b6a
Interestingly, the first index scan after the update does find the row, but
subsequent scans do not.
Here you can see it working on 8.3.0:
https://gist.github.com/d0dbbf29606822b8ceb9
You can grab the test table data dump here:
http://www.frostconsultingllc.com/coordinate_test.dmp
Please contact me if there's anything else you need to reproduce the bug.
Note that if you're using the coordinate_test data, you'll have to set
enable_seqscan = 0 to force an index scan as the table only contains 100
rows.
--- End Message ---
--
Sent via pgsql-bugs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
