Changes between Initial Version and Version 1 of Ticket #3418, comment 12


Ignore:
Timestamp:
01/02/17 21:18:19 (8 years ago)
Author:
robe

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #3418, comment 12

    initial v1  
    4747
    4848----
     49
     50
     51Just for reference, my full post was this:
     52
     53
     54----
     55
     56{{{
     57I've been trying to troubleshoot the cause of this PostGIS recheck bug we
     58have reported by two people so far.  The last test was a nice simple
     59repeatable one that triggered the issue:
     60
     61https://trac.osgeo.org/postgis/ticket/3418
     62
     63
     64from what I have seen this only affects cases where we are doing a distance
     65check between two points, which we actually don't need to enable recheck for
     66anyway, but trying to disable that seems like just shoving the real problem
     67under the covers.
     68Where it errors is this line 272 in src/backend/executor/nodeIndexscan
     69
     70https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/exe
     71cutor/nodeIndexscan.c;h=3143bd94ec4499fba94b41693538b785c4b32e6c;hb=HEAD#l27
     722
     73
     74
     75  /*
     76 259              * Was the ORDER BY value returned by the index accurate?
     77The
     78 260              * recheck flag means that the index can return inaccurate
     79values,
     80 261              * but then again, the value returned for any particular
     81tuple
     82 262              * could also be exactly correct.  Compare the value
     83returned by
     84 263              * the index with the recalculated value.  (If the value
     85returned
     86 264              * by the index happened to be exact right, we can often
     87avoid
     88 265              * pushing the tuple to the queue, just to pop it back out
     89again.)
     90 266              */
     91 267             cmp = cmp_orderbyvals(node->iss_OrderByValues,
     92 268                                   node->iss_OrderByNulls,
     93 269                                   scandesc->xs_orderbyvals,
     94 270                                   scandesc->xs_orderbynulls,
     95 271                                   node);
     96 272             if (cmp < 0)
     97 273                 elog(ERROR, "index returned tuples in wrong order");
     98 274             else if (cmp == 0)
     99 275                 was_exact = true;
     100 276             else
     101 277                 was_exact = false;
     102
     103If things are out of order, why isn't just going to was_exact = false good
     104enough?
     105
     106I'm not sure if the mistake is in our PostGIS code or something in
     107PostgreSQL recheck logic.
     108If I change the elog(ERROR ...) to a elog(NOTICE, the answers  are correct
     109and sort order is right.
     110
     111Under what conditions would cmp return less than 0?  I tried following the
     112code in cmp_orderbyvals, but got lost
     113and trying to put elog notices in to see what the distance is returning (I
     114probably did it wrong), just ended up crashing by backend.
     115
     116
     117Thanks for any thoughts,
     118Regina
     119}}}
     120
     121----
     122
     123
     124The git commit he references we can look for for guidance is this one:
     125https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=35fcb1b3d038a501f3f4c87c05630095abaaadab
     126
     127{{{
     128Allow GiST distance function to return merely a lower-bound.
     129
     130The distance function can now set *recheck = false, like index quals. The
     131executor will then re-check the ORDER BY expressions, and use a queue to
     132reorder the results on the fly.
     133
     134This makes it possible to do kNN-searches on polygons and circles, which
     135don't store the exact value in the index, but just a bounding box.
     136
     137Alexander Korotkov and me
     138}}}
     139
     140