|From:||"Regina Obe" <lr(at)pcorp(dot)us>|
|Subject:||What is "index returned tuples in wrong order" for recheck supposed to guard against?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
I've been trying to troubleshoot the cause of this PostGIS recheck bug we
have reported by two people so far. The last test was a nice simple
repeatable one that triggered the issue:
from what I have seen this only affects cases where we are doing a distance
check between two points, which we actually don't need to enable recheck for
anyway, but trying to disable that seems like just shoving the real problem
under the covers.
Where it errors is this line 272 in src/backend/executor/nodeIndexscan
259 * Was the ORDER BY value returned by the index accurate?
260 * recheck flag means that the index can return inaccurate
261 * but then again, the value returned for any particular
262 * could also be exactly correct. Compare the value
263 * the index with the recalculated value. (If the value
264 * by the index happened to be exact right, we can often
265 * pushing the tuple to the queue, just to pop it back out
267 cmp = cmp_orderbyvals(node->iss_OrderByValues,
272 if (cmp < 0)
273 elog(ERROR, "index returned tuples in wrong order");
274 else if (cmp == 0)
275 was_exact = true;
277 was_exact = false;
If things are out of order, why isn't just going to was_exact = false good
I'm not sure if the mistake is in our PostGIS code or something in
PostgreSQL recheck logic.
If I change the elog(ERROR ...) to a elog(NOTICE, the answers are correct
and sort order is right.
Under what conditions would cmp return less than 0? I tried following the
code in cmp_orderbyvals, but got lost
and trying to put elog notices in to see what the distance is returning (I
probably did it wrong), just ended up crashing by backend.
Thanks for any thoughts,
|Next Message||Michael Paquier||2016-12-30 05:52:53||Re: Potential data loss of 2PC files|
|Previous Message||Tom Lane||2016-12-30 05:44:33||Broken atomics code on PPC with FreeBSD 10.3|