From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GiST KNN Crasher |
Date: | 2015-05-21 21:02:13 |
Message-ID: | 555E47D5.8080000@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/21/2015 11:28 PM, Tom Lane wrote:
> Paul Ramsey <pramsey(at)cleverelephant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Geoff Winkless | 2015-05-21 21:03:26 | Re: INSERT ... ON CONFLICT DO UPDATE with _any_ constraint |
Previous Message | Andres Freund | 2015-05-21 20:53:38 | Re: Fix misaligned access of ItemPointerData on ARM |