Re: GiST KNN Crasher - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: GiST KNN Crasher
Date
Msg-id 555E47D5.8080000@iki.fi
Whole thread Raw
In response to Re: GiST KNN Crasher  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GiST KNN Crasher
List pgsql-hackers
On 05/21/2015 11:28 PM, Tom Lane wrote:
> Paul Ramsey <pramsey@cleverelephant.ca> writes:
>> I'm implementing the recheck functionality for PostGIS so we can
>> support it when 9.5 comes out, and came across this fun little
>> crasher.
>
> Hmm, works in 9.3 and 9.4, so it's been broken recently.

It was clearly broken by knn-with-recheck patch (35fcb1b3), which added 
the code where the segfault happened.

The find_ec_member_for_expr() call in create_indexscan_plan() fails to 
find the equivalence member for the path key. 
match_clause_to_ordering_op() found the match by commuting the operator, 
but code in create_indexscan_plan() doesn't take that into account.

I think that trying to find the equivalence member in 
create_index_scan() is too fragile. I'm not too familiar with the 
equivalence class stuff though, so I'm not sure what the correct 
solution is. Could we store the datatype in the IndexPath to begin with, 
to avoid having to deduce it in create_indexscan_plan()? Or could we 
just use exprType() on the expression in create_indexscan_plan() and not 
bother finding the equivalence member? The comments in EquivalenceMember 
suggest that that won't work in particular with anyarray_ops, but to be 
honest this goes beyond my planner skills..

- Heikki



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Fix misaligned access of ItemPointerData on ARM
Next
From: Geoff Winkless
Date:
Subject: Re: INSERT ... ON CONFLICT DO UPDATE with _any_ constraint